[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From jvdelisle at verizon dot net 2005-06-08 06:04 --- This is looking much better now. Compiled with -O2 -march=pentium4 gcc version 4.1.0 20050607 (experimental) CGV drivers: 64 out of 1092 tests failed to pass the threshold DXV drivers:200 out of 5000 tests failed to pass the threshold SXV drivers: 37 out of 5000 tests failed to pass the threshold SST:1 out of 4662 tests failed to pass the threshold SST drivers: 1 out of 14256 tests failed to pass the threshold ZGV drivers: 65 out of 1092 tests failed to pass the threshold ZXV drivers: 24 out of 5000 tests failed to pass the threshold -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug c/21957] New: IA-64 register stack is not preserved after getcontext call
I found that following code causes SEGV on IA-64 Debian GNU/Linux (sarge) with
gcc-4.0 -O1. The code uses getcontext and setcontext which is defined by Single
Unix Specification. rx1620% cat tst.i typedef long unsigned int
size_t; struct ia64_fpreg { union { unsigned long
bits[2]; long double __dummy; } u; }; typedef struct
sigaltstack { void * ss_sp; int ss_flags; size_t ss_size; }
stack_t; struct sigcontext { unsigned long int sc_flags; unsigned long int
sc_nat; stack_t sc_stack;unsigned long int sc_ip; unsigned long int
sc_cfm; unsigned long int sc_um; unsigned long int sc_ar_rsc; unsigned
long int sc_ar_bsp; unsigned long int sc_ar_rnat; unsigned long int
sc_ar_ccv; unsigned long int sc_ar_unat; unsigned long int sc_ar_fpsr;
unsigned long int sc_ar_pfs; unsigned long int sc_ar_lc; unsigned long int
sc_pr; unsigned long int sc_br[8]; unsigned long int sc_gr[32]; struct
ia64_fpreg sc_fr[128]; unsigned long int sc_rbs_base; unsigned long int
sc_loadrs; unsigned long int sc_ar25; unsigned long int sc_ar26; unsigned
long int sc_rsvd[12];unsigned long int sc_mask; }; typedef struct
sigcontext mcontext_t; typedef struct ucontext { union {
mcontext_t _mc; struct { unsigned long
_pad[(((char *) ((struct sigcontext *) 0)-sc_gr[0]) - (char *) 0)/8];
struct ucontext *_link; } _uc; } _u; }
ucontext_t; extern int getcontext (ucontext_t *__ucp) ; extern int setcontext
(__const ucontext_t *__ucp) ; int flag; ucontext_t cont; static void f(void)
{ flag = 1; setcontext(cont); } static int g(void) { int ret;flag =
0; getcontext(cont); ret = flag; if (ret == 0) { f(); } return
ret; } int main(int argc, char **argv) { g(); return 0; } rx1620%
/home/src/gcc/4.0/bin/gcc -v -g -O1 tst.i Using built-in specs. Target:
ia64-unknown-linux-gnu Configured with: ../gcc/configure
--prefix=/home/src/gcc/4.0 --enable-languages=c Thread model: posix gcc version
4.0.1 20050607 (prerelease)
/home/src/gcc/4.0/libexec/gcc/ia64-unknown-linux-gnu/4.0.1/cc1 -fpreprocessed
tst.i -quiet -dumpbase tst.i -auxbase tst -g -O1 -version -o /tmp/ccGs6ixv.s
GNU C version 4.0.1 20050607 (prerelease) (ia64-unknown-linux-gnu)
compiled by GNU C version 4.0.1 20050607 (prerelease). GGC heuristics: --param
ggc-min-expand=100 --param ggc-min-heapsize=131072 as -x -o /tmp/ccgROVXU.o
/tmp/ccGs6ixv.s
/home/src/gcc/4.0/libexec/gcc/ia64-unknown-linux-gnu/4.0.1/collect2
-dynamic-linker /lib/ld-linux-ia64.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/home/src/gcc/4.0/lib/gcc/ia64-unknown-linux-gnu/4.0.1/crtbegin.o
-L/home/src/gcc/4.0/lib/gcc/ia64-unknown-linux-gnu/4.0.1
-L/home/src/gcc/4.0/lib/gcc/ia64-unknown-linux-gnu/4.0.1/../../..
/tmp/ccgROVXU.o -lgcc --as-needed -lgcc_s -lunwind --no-as-needed -lc -lgcc
--as-needed -lgcc_s -lunwind --no-as-needed
/home/src/gcc/4.0/lib/gcc/ia64-unknown-linux-gnu/4.0.1/crtend.o /usr/lib/crtn.o
rx1620% ./a.out zsh: segmentation fault (core
dumped) ./a.out rx1620% uname -a Linux rx1620 2.4.25-hpe-9-mckinley-smp #1 SMP
Wed Aug 11 11:59:05 UTC 2004 ia64 GNU/Linux
The generated assembly code is
follows. | rx1620% /home/src/gcc/4.0/bin/gcc -O1 -S tst.i| rx1620% cat
tst.s | .file tst.i |
.pred.safe_across_calls p1-p5,p16-p63 | .text | .align 16 |
.proc f# | f: | .prologue 12, 32 | .save ar.pfs, r33 |
alloc r33 = ar.pfs, 0, 3, 1, 0 | mov r34 = r1 | .save rp,
r32 | mov r32 = b0 | .body | addl r15 = 1, r0 |
addl r14 = @ltoffx(flag#), r1 | ;; | ld8.mov r14 = [r14], flag#
| ;; | st4 [r14] = r15 | addl r35 = @ltoffx(cont#), r1
| ;; | ld8.mov r35 = [r35], cont# | br.call.sptk.many
b0 = setcontext# | mov r1 = r34 | ;; | mov ar.pfs = r33
| mov b0 = r32 | br.ret.sptk.many b0 | ;; |
.endp f# | .align 16 | .proc g# | g: | .prologue 12, 33
| .save ar.pfs, r34 | alloc r34 = ar.pfs, 0, 4, 1, 0 |
mov r35 = r1 | .save rp, r33 | mov r33 = b0 | .body |
addl r32 = @ltoffx(flag#), r1 | ;; | ld8.mov r32 = [r32],
flag# r32 is set. | ;; | st4 [r32] = r0 | addl r36 =
@ltoffx(cont#), r1 | ;; | ld8.mov r36 = [r36], cont# |
br.call.sptk.many b0 = getcontext# getcontext is called. | mov r1 =
r35 | ld4 r32 = [r32] r32 is used. This means that the code expects
r32 is preserved after getcontext returns. | ;; | cmp4.ne p6,
[Bug c/21957] IA-64 register stack is not preserved after getcontext call
--- Additional Comments From akr at m17n dot org 2005-06-08 06:19 ---
Oops. The newlines are squashed. I repeat the report as this comment.
I found that following code causes SEGV on IA-64 Debian GNU/Linux (sarge)
with gcc-4.0 -O1.
The code uses getcontext and setcontext which is defined by
Single Unix Specification.
rx1620% cat tst.i
typedef long unsigned int size_t;
struct ia64_fpreg {
union {
unsigned long bits[2];
long double __dummy;
} u;
};
typedef struct sigaltstack
{
void * ss_sp;
int ss_flags;
size_t ss_size;
} stack_t;
struct sigcontext
{
unsigned long int sc_flags;
unsigned long int sc_nat;
stack_t sc_stack;
unsigned long int sc_ip;
unsigned long int sc_cfm;
unsigned long int sc_um;
unsigned long int sc_ar_rsc;
unsigned long int sc_ar_bsp;
unsigned long int sc_ar_rnat;
unsigned long int sc_ar_ccv;
unsigned long int sc_ar_unat;
unsigned long int sc_ar_fpsr;
unsigned long int sc_ar_pfs;
unsigned long int sc_ar_lc;
unsigned long int sc_pr;
unsigned long int sc_br[8];
unsigned long int sc_gr[32];
struct ia64_fpreg sc_fr[128];
unsigned long int sc_rbs_base;
unsigned long int sc_loadrs;
unsigned long int sc_ar25;
unsigned long int sc_ar26;
unsigned long int sc_rsvd[12];
unsigned long int sc_mask;
};
typedef struct sigcontext mcontext_t;
typedef struct ucontext
{
union
{
mcontext_t _mc;
struct
{
unsigned long _pad[(((char *) ((struct sigcontext *) 0)-sc_gr[0])
- (char *) 0)/8];
struct ucontext *_link;
}
_uc;
}
_u;
}
ucontext_t;
extern int getcontext (ucontext_t *__ucp) ;
extern int setcontext (__const ucontext_t *__ucp) ;
int flag;
ucontext_t cont;
static void f(void)
{
flag = 1;
setcontext(cont);
}
static int
g(void)
{
int ret;
flag = 0;
getcontext(cont);
ret = flag;
if (ret == 0) {
f();
}
return ret;
}
int main(int argc, char **argv)
{
g();
return 0;
}
rx1620% /home/src/gcc/4.0/bin/gcc -v -g -O1 tst.i
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/home/src/gcc/4.0
--enable-languages=c
Thread model: posix
gcc version 4.0.1 20050607 (prerelease)
/home/src/gcc/4.0/libexec/gcc/ia64-unknown-linux-gnu/4.0.1/cc1 -fpreprocessed
tst.i -quiet -dumpbase tst.i -auxbase tst -g -O1 -version -o /tmp/ccGs6ixv.s
GNU C version 4.0.1 20050607 (prerelease) (ia64-unknown-linux-gnu)
compiled by GNU C version 4.0.1 20050607 (prerelease).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
as -x -o /tmp/ccgROVXU.o /tmp/ccGs6ixv.s
/home/src/gcc/4.0/libexec/gcc/ia64-unknown-linux-gnu/4.0.1/collect2
-dynamic-linker /lib/ld-linux-ia64.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/home/src/gcc/4.0/lib/gcc/ia64-unknown-linux-gnu/4.0.1/crtbegin.o
-L/home/src/gcc/4.0/lib/gcc/ia64-unknown-linux-gnu/4.0.1
-L/home/src/gcc/4.0/lib/gcc/ia64-unknown-linux-gnu/4.0.1/../../..
/tmp/ccgROVXU.o -lgcc --as-needed -lgcc_s -lunwind --no-as-needed -lc -lgcc
--as-needed -lgcc_s -lunwind --no-as-needed
/home/src/gcc/4.0/lib/gcc/ia64-unknown-linux-gnu/4.0.1/crtend.o /usr/lib/crtn.o
rx1620% ./a.out
zsh: segmentation fault (core dumped) ./a.out
rx1620% uname -a
Linux rx1620 2.4.25-hpe-9-mckinley-smp #1 SMP Wed Aug 11 11:59:05 UTC 2004 ia64
GNU/Linux
The generated assembly code is follows.
| rx1620% /home/src/gcc/4.0/bin/gcc -O1 -S tst.i
| rx1620% cat tst.s
| .file tst.i
| .pred.safe_across_calls p1-p5,p16-p63
| .text
| .align 16
| .proc f#
| f:
| .prologue 12, 32
| .save ar.pfs, r33
| alloc r33 = ar.pfs, 0, 3, 1, 0
| mov r34 = r1
| .save rp, r32
| mov r32 = b0
| .body
| addl r15 = 1, r0
| addl r14 = @ltoffx(flag#), r1
| ;;
| ld8.mov r14 = [r14], flag#
| ;;
| st4 [r14] = r15
| addl r35 = @ltoffx(cont#), r1
| ;;
| ld8.mov r35 = [r35], cont#
| br.call.sptk.many b0 = setcontext#
| mov r1 = r34
| ;;
| mov ar.pfs = r33
| mov b0 = r32
| br.ret.sptk.many b0
| ;;
| .endp f#
| .align 16
| .proc g#
| g:
| .prologue 12, 33
| .save ar.pfs, r34
| alloc r34 = ar.pfs, 0, 4, 1, 0
| mov r35 = r1
| .save rp, r33
| mov r33 = b0
| .body
| addl r32 = @ltoffx(flag#), r1
| ;;
| ld8.mov r32 = [r32], flag#
r32 is set.
| ;;
| st4 [r32] = r0
| addl r36 = @ltoffx(cont#), r1
| ;;
| ld8.mov r36 = [r36], cont#
| br.call.sptk.many b0 = getcontext#
getcontext is called.
| mov r1 = r35
| ld4 r32 = [r32]
r32 is used.
This means that the code
[Bug middle-end/21957] IA-64 register stack is not preserved after getcontext call
-- What|Removed |Added Component|c |middle-end Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21957
[Bug target/21721] [4.0 regression] fails to assemble, Use of p0 is not valid in this context
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-08 07:27 --- Subject: Bug 21721 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-08 07:27:01 Modified files: gcc: ChangeLog gcc/config/ia64: ia64.c Log message: PR target/21721 * config/ia64/ia64.c (emit_predicate_relation_info): Skip p0. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9085r2=2.9086 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gccr1=1.371r2=1.372 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21721
[Bug debug/21946] [4.0 Regression] Invalid DWARF2 debug info emitted
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-08 07:48 --- Subject: Bug 21946 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-08 07:48:28 Modified files: gcc: ChangeLog dwarf2out.c Log message: PR debug/21946 * dwarf2out.c (add_loc_descr_op_piece): Move to the DWARF2_DEBUGGING_INFO section. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9086r2=2.9087 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gccr1=1.599r2=1.600 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21946
[Bug fortran/21063] ICE in gfc_conv_ss_descriptor, at fortran/trans-array.c:1224 after using maxloc function
--- Additional Comments From c dot lemmen at fz-juelich dot de 2005-06-08 08:23 --- The numerical recipes library seems to be affected by this bug in file src/wtn.f90 with gcc-Version 4.1.0 20050608 (experimental) on linux-x68-smp -- What|Removed |Added CC||c dot lemmen at fz-juelich ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21063
[Bug fortran/18108] [gfortran] overloading does not work for functions
--- Additional Comments From c dot lemmen at fz-juelich dot de 2005-06-08 08:57 --- Surprisingly (to me), adding a second call to the function resolves the problem, i.e. in the examples below the following code works subroutine baz logical l l = bar (3) l = bar (3) ! alternatively, call l=bar(3.0) end subroutine I verified that it actually calls the right routine under these circumstances. From the compiler output with -fump-parse-tree: ASSIGN l bar_real[[((3.000))]] ASSIGN l bar_real[[((3.000))]] Does this mean that calling twice is a verified workaround solution? Should I have confidence in the results of this workaround? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18108
[Bug fortran/18108] [gfortran] overloading does not work for functions
--- Additional Comments From martin at mpa-garching dot mpg dot de 2005-06-08 09:02 --- (In reply to comment #10) Does this mean that calling twice is a verified workaround solution? Should I have confidence in the results of this workaround? Even if it was, this is not a practical solution in for large code bases like the one I have to maintain. What's worrying me most is that nobody appears to understand what's going wrong. (And that for a very long time now.) Since half a year, this is the one bug preventing me from using gfortran to compile my code base and report more bugs :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18108
[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-08 09:38 --- Can you try and figure out which patch changed this for GCC 4.1? Bonus points if you can see if backporting that patch gives GCC 4.0 a speed-up, because in that case you may have something to go to Mark with for the next GCC 4.0.x (x1) release ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097
[Bug tree-optimization/21029] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From schwab at suse dot de 2005-06-08 09:45 --- This is still not fixed. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug tree-optimization/21861] [meta-bug] scalar evolution type conversion
-- Bug 21861 depends on bug 21029, which changed state. Bug 21029 Summary: [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21861
[Bug fortran/18108] [gfortran] overloading does not work for functions
--- Additional Comments From c dot lemmen at fz-juelich dot de 2005-06-08 10:20 --- Subject: Re: [gfortran] overloading does not work for functions martin at mpa-garching dot mpg dot de wrote: --- Additional Comments From martin at mpa-garching dot mpg dot de 2005-06-08 09:02 --- (In reply to comment #10) Even if it was, this is not a practical solution in for large code bases like the one I have to maintain. What's worrying me most is that nobody appears to understand what's going wrong. (And that for a very long time now.) Since half a year, this is the one bug preventing me from using gfortran to compile my code base and report more bugs :( Not practical...yeah. I'm only beginning to see the effort of doubling all statements of calls to generic functions in my (rather large) codebase... For the part that I implemented, everything seems to work fine, large parts of the code now compile and those that don't give rise to more bug reports. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18108
[Bug c++/19894] pointer-to-void member not rejected in template
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-08 11:09 --- Subject: Bug 19894 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-08 11:09:13 Modified files: gcc/cp : ChangeLog parser.c pt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/ext: label4.C gcc/testsuite/g++.dg/template: ptrmem15.C Log message: PR c++/19894 * pt.c (tsubst): Reject pointer-to-member of type void. * g++.dg/template/ptrmem15.C: New test. PR c++/20563 * parser.c (cp_parser_label_declaration): Deal with invalid/missing identifiers. * g++.dg/ext/label4.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4781r2=1.4782 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gccr1=1.339r2=1.340 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.1003r2=1.1004 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5612r2=1.5613 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/label4.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/ptrmem15.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19894
[Bug c++/20563] [3.4/4.0/4.1 Regression] Infinite loop in diagnostic (and ice after error message)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-08 11:09 --- Subject: Bug 20563 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-08 11:09:13 Modified files: gcc/cp : ChangeLog parser.c pt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/ext: label4.C gcc/testsuite/g++.dg/template: ptrmem15.C Log message: PR c++/19894 * pt.c (tsubst): Reject pointer-to-member of type void. * g++.dg/template/ptrmem15.C: New test. PR c++/20563 * parser.c (cp_parser_label_declaration): Deal with invalid/missing identifiers. * g++.dg/ext/label4.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4781r2=1.4782 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gccr1=1.339r2=1.340 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.1003r2=1.1004 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5612r2=1.5613 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/label4.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/ptrmem15.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20563
[Bug c++/19894] pointer-to-void member not rejected in template
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-08 11:12 --- Fixed in mainline (will become GCC 4.1.0). -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19894
[Bug c++/20563] [3.4/4.0/4.1 Regression] Infinite loop in diagnostic (and ice after error message)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-08 11:26 --- Subject: Bug 20563 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-06-08 11:26:06 Modified files: gcc/cp : ChangeLog parser.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/ext: label4.C Log message: PR c++/20563 * parser.c (cp_parser_label_declaration): Deal with invalid/missing identifiers. * g++.dg/ext/label4.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3892.2.222r2=1.3892.2.223 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.157.2.55r2=1.157.2.56 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.401r2=1.3389.2.402 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/ext/label4.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20563
[Bug fortran/18108] [gfortran] overloading does not work for functions
--- Additional Comments From c dot lemmen at fz-juelich dot de 2005-06-08 11:28 --- Subject: Re: [gfortran] overloading does not work for functions -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lots of previously working code (somewhere around December 2004) now (June 2005) exhibits this bug, it seems that this bug is a side-effect of something else. Call it a regression ? Sorry for not being able to pin down when this regression occurred. Cheers, CL -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCptZP9OR+vL2Y8M8RAkBbAJ9CvatWfbsWC7evKqM2NVpLGjYGmQCfb5LQ tjBco+Njl2ax7EXyXWwxzFA= =KDzi -END PGP SIGNATURE- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18108
[Bug c++/20563] [4.0 Regression] Infinite loop in diagnostic (and ice after error message)
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-08 11:28 --- Fixed on mainline (will become GCC 4.1.0) and the 3.4-branch (will become GCC 3.4.5). Waiting for the 4.0 branch to thaw. -- What|Removed |Added Summary|[3.4/4.0/4.1 Regression]|[4.0 Regression] Infinite |Infinite loop in diagnostic |loop in diagnostic (and ice |(and ice after error|after error message) |message)| Target Milestone|3.4.5 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20563
[Bug c++/19497] [3.4/4.0/4.1 regression] Invalid declaration in template diagnosed too late
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-08 11:49 --- Subject: Bug 19497 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-08 11:49:24 Modified files: gcc/cp : ChangeLog class.c cp-tree.def cp-tree.h cxx-pretty-print.c name-lookup.c name-lookup.h pt.c search.c semantics.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/inherit: using5.C using6.C Log message: cp: PR c++/19497 * cp-tree.def (USING_DECL): Update documentation. * cp-tree.h (DECL_DEPENDENT_P): New. (USING_DECL_DECLS, USING_DECL_SCOPE): New. * class.c (handle_using_decl): Move most of the processing to ... * name-lookup.c (do_class_using_decl): ... here. Make stricter. (push_using_decl): Use USING_DECL_SCOPE. (cp_emit_debug_info_for_using): Make extern. * cxx-pretty-print.c (pp_cxx_statement) USING_DECL case: Adjust. * name-lookup.h (cp_emit_debug_info_for_using): Declare. * pt.c (tsubst_decl) USING_DECL case: Use do_class_using_decl when tsubsting. (tsubst_expr): Use USING_DECL_SCOPE. * search.c (lookup_field_1): Use DECL_DEPENDENT_P. * semantics.c (finish_member_declaration): Likewise. testsuite: PR c++/19497 * g++.dg/inherit/using5.C: New. * g++.dg/inherit/using6.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4782r2=1.4783 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gccr1=1.719r2=1.720 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.def.diff?cvsroot=gccr1=1.104r2=1.105 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gccr1=1.1143r2=1.1144 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cxx-pretty-print.c.diff?cvsroot=gccr1=1.34r2=1.35 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.c.diff?cvsroot=gccr1=1.122r2=1.123 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/name-lookup.h.diff?cvsroot=gccr1=1.40r2=1.41 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.1004r2=1.1005 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/search.c.diff?cvsroot=gccr1=1.346r2=1.347 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gccr1=1.474r2=1.475 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5613r2=1.5614 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/using5.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/using6.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19497
[Bug c++/19497] [3.4/4.0/4.1 regression] Invalid declaration in template diagnosed too late
--- Additional Comments From nathan at gcc dot gnu dot org 2005-06-08 11:51 --- 2005-06-08 Nathan Sidwell [EMAIL PROTECTED] PR c++/19497 * cp-tree.def (USING_DECL): Update documentation. * cp-tree.h (DECL_DEPENDENT_P): New. (USING_DECL_DECLS, USING_DECL_SCOPE): New. * class.c (handle_using_decl): Move most of the processing to ... * name-lookup.c (do_class_using_decl): ... here. Make stricter. (push_using_decl): Use USING_DECL_SCOPE. (cp_emit_debug_info_for_using): Make extern. * cxx-pretty-print.c (pp_cxx_statement) USING_DECL case: Adjust. * name-lookup.h (cp_emit_debug_info_for_using): Declare. * pt.c (tsubst_decl) USING_DECL case: Use do_class_using_decl when tsubsting. (tsubst_expr): Use USING_DECL_SCOPE. * search.c (lookup_field_1): Use DECL_DEPENDENT_P. * semantics.c (finish_member_declaration): Likewise. Fixed mainline, will not fix on 4.0 -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19497
[Bug c/21958] New: verify_stmts reports tree node sharing assertion
Using GCC 4.1 mainline checkout at 20050607.
$ ./i686-linux/gcc/xgcc -B ./i686-linux/gcc -S bug1.c -O1
bug1.c: In function foo:
bug1.c:2: error: Incorrect sharing of tree nodes
D.1290_47 = (charD.1 * *) pD.1236_3;
(charD.1 * *) pD.1236_3;
bug1.c:2: internal compiler error: verify_stmts failed.
Please submit a full bug report,
I've narrowed down a testcase to:
void foo (char *p)
{
char *endptr = p;
while (1)
{
int i = 1;
char **members;
if (p[1])
{
do {
if (*p == ',')
{
i++;
*p = 0;
}
} while (*++p);
}
members = (char **) p;
if (--i)
{
p = endptr;
do {
*members++ = ++p;
if (!--i)
break;
while (*++p) {}
} while (1);
}
*members = 0;
}
}
--
Summary: verify_stmts reports tree node sharing assertion
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nick at sqrt dot co dot uk
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=21958
[Bug testsuite/21702] Typo in gcc/testsuite/gcc.target/i386/i386.exp
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-08 12:02 --- Subject: Bug 21702 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-08 12:02:20 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/gcc.target/i386: i386.exp Log message: PR testsuite/21702 * gcc.target/i386/i386.exp: Fix comment typo. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5614r2=1.5615 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/i386.exp.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21702
[Bug testsuite/21702] Typo in gcc/testsuite/gcc.target/i386/i386.exp
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-08 12:10 --- Fixed in mainline. Thanks for spotting this! -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21702
[Bug fortran/18157] ice-on-valid code, pointer to user-defined type, fold-struct.c
--- Additional Comments From c dot lemmen at fz-juelich dot de 2005-06-08 12:19 --- Bug persists in GNU F95 version 4.1.0 20050608, line number is now testing/testcase_fold.f90: In Funktion »MAIN__«: testing/testcase_fold.f90:22: interner Compiler-Fehler: in fold_convert, bei fold-const.c:2029 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18157
[Bug ada/20530] gnatlink does not respect -mno-cygwin
--- Additional Comments From gerrit at gcc dot gnu dot org 2005-06-08 12:22 --- (In reply to comment #2) Right, gnatmake has never supported -mno-cygwin. Instead, I'd suggest configuring gcc for mingw to start with. According to http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Option-Index.html#Option-Index -mno-cygwin is not a FSF option, so closing this PR. Arno Many thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20530
[Bug tree-optimization/21861] [meta-bug] scalar evolution type conversion
-- Bug 21861 depends on bug 21029, which changed state. Bug 21029 Summary: [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029 What|Old Value |New Value Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21861
[Bug tree-optimization/21029] [4.1 Regression] vrp miscompiles Ada front-end, drops loop exit test in well-defined wrap-around circumstances
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 12:29 --- (In reply to comment #19) This is still not fixed. But this time it is not VRP which is causing the problem but the Ada front-end, I will file a new bug. -- What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21029
[Bug ada/21959] New: [4.1 Regression] Ada depeends on signed overflow
See http://gcc.gnu.org/ml/gcc/2005-06/msg00059.html for the full description. -- Summary: [4.1 Regression] Ada depeends on signed overflow Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code, build Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
[Bug ada/21959] [4.1 Regression] Ada depeends on signed overflow
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 12:32 --- Confirmed based on the whole thread. -- What|Removed |Added CC||schwab at suse dot de Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-08 12:32:26 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21959
[Bug ada/20530] gnatlink does not respect -mno-cygwin
--- Additional Comments From gerrit at gcc dot gnu dot org 2005-06-08 12:40 --- According to http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Option-Index.html#Option-Index -mno-cygwin is not a FSF option, so closing this PR. This option just triggers gcc to use other lib and include paths, as they are defined in the specs. So it seems gnat doesn't use the specs when linking. Note that it works quite well with include paths when compiling the source? I will provide a workaround in the upcoming release of cygwin gcc-3.4.4, in addition to -mno-cygwin another flag is needed then: --RTS=no-cygwin This will cause gnat to pick up the right runtime if the gcc-mingw-ada package is correctly installed. Then there is a new subdirectory in i686-pc-cygwin/3.4.4 named no-cygwin with symlinks to the mingw runtime: /---3.4.4 | /---adainclude | /---adalib | /---no-cygwin | +---adainclude | +---adalib $ gcc -v -c --RTS=no-cygwin -mno-cygwin hello_a.adb Reading specs from /usr/lib/gcc/i686-pc-mingw32/3.4.4/specs Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug : (reconfigured) Thread model: posix gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) /usr/lib/gcc/i686-pc-mingw32/3.4.4/gnat1.exe -quiet -dumpbase hello_a.adb -mno-cygwin -mtune=pentiumpro -fRTS=no-cygwin hello_a.adb -o /tmp/ccqn0PMb.s /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/bin/as.exe -o hello_a.o /tmp/ccqn0PMb.s $ gnatbind -v -aO./ --RTS=no-cygwin -I- -x hello_a.ali GNATBIND 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright 1995-2004 Free Software Foundation, Inc. Binding: hello_a.ali No errors $ gnatlink hello_a.ali -mno-cygwin -v GNATLINK 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) Copyright 1995-2004 Free Software Foundation, Inc gcc -c -gnatA -gnatWb -gnatiw -mno-cygwin -mtune=pentiumpro --RTS=no-cygwin -gnatws b~hello_a.adb /usr/bin/gcc.exe b~hello_a.o ./hello_a.o -mno-cygwin -o hello_a.exe -L./ -L/usr/lib/gcc/i686-pc-cygwin/3.4.4/no-cygwin/adalib/ /usr/lib/gcc/i686-pc-cygwin/3.4.4/no-cygwin/adalib/libgnat.a -Wl,--stack=0x200 $ cygcheck hello_a.exe Found: h:\cygwin\gcc\gcc-test\hello_a.exe h:/cygwin/gcc/gcc-test/hello_a.exe C:\WINNT\System32\msvcrt.dll C:\WINNT\System32\KERNEL32.dll C:\WINNT\System32\ntdll.dll C:\WINNT\System32\ADVAPI32.DLL C:\WINNT\System32\USER32.dll C:\WINNT\System32\GDI32.dll C:\WINNT\System32\RPCRT4.dll Running this executable works fine. I'll try to find a way to integrate this in to the binary to make it work as one expect it to work. Gerrit -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20530
[Bug c++/19497] [3.4/4.0/4.1 regression] Invalid declaration in template diagnosed too late
-- What|Removed |Added Known to work||4.1.0 Target Milestone|3.4.5 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19497
[Bug rtl-optimization/19097] [3.4/4.0/4.1 regression] Quadratic behavior with many sets for the same register in gcse CPROP
--- Additional Comments From phython at gcc dot gnu dot org 2005-06-08 12:43 --- Ok, I seem to be wrong, hash_set still seems to be used for implicit sets. However, the destination registers in gcc 4.1 are all different: SET hash table (1251 buckets, 1001 entries) Index 0 (hash value 339) (set (reg/v:SI 339 [ b ]) (const_int 1 [0x1])) Index 1 (hash value 342) (set (reg:SI 342) (const_int 1000 [0x3e8])) Index 2 (hash value 344) (set (reg:SI 344) (const_int 1001 [0x3e9])) Index 3 (hash value 346) (set (reg:SI 346) (const_int 1002 [0x3ea])) Index 4 (hash value 348) (set (reg:SI 348) (const_int 1003 [0x3eb])) Index 5 (hash value 350) (set (reg:SI 350) (const_int 1004 [0x3ec])) Index 6 (hash value 352) (set (reg:SI 352) (const_int 1005 [0x3ed])) Index 7 (hash value 354) ... Index 999 (hash value 1087) (set (reg:SI 2338) (const_int 1998 [0x7ce])) Index 1000 (hash value 1089) (set (reg:SI 2340) (const_int 1999 [0x7cf])) And the time report for -O2 using CL4 on ia64-linux Execution times (seconds) garbage collection: 1.98 ( 1%) usr 0.00 ( 0%) sys 1.98 ( 1%) wall 0 kB ( 0%) ggc dump files: 1.03 ( 0%) usr 0.06 ( 4%) sys 1.08 ( 0%) wall 0 kB ( 0%) ggc callgraph construction: 4.20 ( 1%) usr 0.01 ( 1%) sys 4.21 ( 1%) wall 12188 kB ( 7%) ggc cfg construction : 0.11 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall 2131 kB ( 1%) ggc cfg cleanup : 1.56 ( 0%) usr 0.00 ( 0%) sys 1.56 ( 0%) wall 568 kB ( 0%) ggc CFG verifier : 7.19 ( 2%) usr 0.02 ( 1%) sys 7.21 ( 2%) wall 0 kB ( 0%) ggc trivially dead code : 0.54 ( 0%) usr 0.00 ( 0%) sys 0.54 ( 0%) wall 0 kB ( 0%) ggc life analysis : 4.12 ( 1%) usr 0.00 ( 0%) sys 4.12 ( 1%) wall 4688 kB ( 3%) ggc life info update : 0.83 ( 0%) usr 0.00 ( 0%) sys 0.83 ( 0%) wall 1250 kB ( 1%) ggc alias analysis: 1.02 ( 0%) usr 0.00 ( 0%) sys 1.02 ( 0%) wall 4096 kB ( 2%) ggc register scan : 0.42 ( 0%) usr 0.00 ( 0%) sys 0.42 ( 0%) wall 0 kB ( 0%) ggc rebuild jump labels : 0.12 ( 0%) usr 0.00 ( 0%) sys 0.12 ( 0%) wall 0 kB ( 0%) ggc preprocessing : 0.11 ( 0%) usr 0.07 ( 4%) sys 0.20 ( 0%) wall 702 kB ( 0%) ggc lexical analysis : 0.08 ( 0%) usr 0.14 ( 8%) sys 0.21 ( 0%) wall 0 kB ( 0%) ggc parser: 0.22 ( 0%) usr 0.06 ( 4%) sys 0.28 ( 0%) wall 5672 kB ( 3%) ggc tree gimplify : 0.13 ( 0%) usr 0.00 ( 0%) sys 0.13 ( 0%) wall 625 kB ( 0%) ggc tree eh : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.23 ( 0%) usr 0.00 ( 0%) sys 0.23 ( 0%) wall 17418 kB (10%) ggc tree CFG cleanup : 1.64 ( 0%) usr 0.00 ( 0%) sys 1.65 ( 0%) wall 0 kB ( 0%) ggc tree VRP : 30.28 ( 9%) usr 0.02 ( 1%) sys 30.31 ( 9%) wall 5568 kB ( 3%) ggc tree copy propagation : 0.60 ( 0%) usr 0.01 ( 1%) sys 0.61 ( 0%) wall 2 kB ( 0%) ggc tree store copy prop : 0.12 ( 0%) usr 0.00 ( 0%) sys 0.12 ( 0%) wall 0 kB ( 0%) ggc tree find ref. vars : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc tree PTA : 0.20 ( 0%) usr 0.00 ( 0%) sys 0.20 ( 0%) wall 0 kB ( 0%) ggc tree alias analysis : 0.29 ( 0%) usr 0.10 ( 6%) sys 0.42 ( 0%) wall 2 kB ( 0%) ggc tree PHI insertion: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree SSA rewrite : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 0 kB ( 0%) ggc tree SSA other: 0.15 ( 0%) usr 0.02 ( 1%) sys 0.17 ( 0%) wall 2 kB ( 0%) ggc tree SSA incremental : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 0 kB ( 0%) ggc tree operand scan : 58.50 (18%) usr 0.17 (11%) sys 58.63 (17%) wall 1354 kB ( 1%) ggc dominator optimization: 1.51 ( 0%) usr 0.00 ( 0%) sys 1.51 ( 0%) wall 10313 kB ( 6%) ggc tree STORE-CCP: 0.14 ( 0%) usr 0.00 ( 0%) sys 0.14 ( 0%) wall 0 kB ( 0%) ggc tree CCP : 0.15 ( 0%) usr 0.00 ( 0%) sys 0.15 ( 0%) wall 0 kB ( 0%) ggc tree split crit edges : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree reassociation: 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree PRE : 0.28 ( 0%) usr 0.01 ( 0%) sys 0.29 ( 0%) wall 0 kB ( 0%) ggc tree FRE : 0.17 ( 0%) usr 0.02 ( 1%) sys 0.19 ( 0%) wall 0 kB ( 0%) ggc tree code sinking : 0.21 ( 0%) usr 0.00 ( 0%) sys 0.21 ( 0%) wall 0 kB ( 0%) ggc tree linearize phis : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 0 kB ( 0%) ggc tree forward propagate: 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc
[Bug target/18333] mmix-knuth-mmixware testsuite failure: gcc.dg/compat/struct-layout-1 generator
--- Additional Comments From hp at gcc dot gnu dot org 2005-06-08 12:50 --- I haven't mentioned before that the host gcc is 2.95.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18333
[Bug tree-optimization/21958] [4.1 Regression] verify_stmts reports tree node sharing assertion
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 12:54 --- Fixed already by: 2005-06-08 Zdenek Dvorak [EMAIL PROTECTED] * tree-ssa-loop-ivopts.c (rewrite_use_outer): Unshare the expression before emiting it. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |tree-optimization Keywords||ice-on-valid-code Resolution||FIXED Summary|verify_stmts reports tree |[4.1 Regression] |node sharing assertion |verify_stmts reports tree ||node sharing assertion Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21958
[Bug testsuite/18333] gcc.dg/compat/struct-layout-1 generator cannot be compiled with gcc 2.95
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-06-08 12:57 --- The same happens on i686-pc-linux-gnu bootstrapping mainline with gcc 2.95.4 (aka gcc-2.95.4-14 from Debian woody). So it seems to be a host compiler bug or at least is host compiler dependent. From gcc 3.0 on it seems to work. -- What|Removed |Added Component|target |testsuite Summary|mmix-knuth-mmixware |gcc.dg/compat/struct-layout- |testsuite failure: |1 generator cannot be |gcc.dg/compat/struct-layout-|compiled with gcc 2.95 |1 generator | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18333
[Bug rtl-optimization/21956] [4.1 Regression] useless symbols in object files
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 13:00 --- Confirmed and this is a regression too. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-06-08 13:00:17 date|| Summary|useless symbols in object |[4.1 Regression] useless |files |symbols in object files Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21956
[Bug inline-asm/20382] internal compiler error with bogus asm output constraint
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 13:14 --- Fixed in 4.1.0 by: 2005-05-08 Roger Sayle [EMAIL PROTECTED] PR inline-asm/8788 * stmt.c (expand_asm_operands): Avoid calling force_reg on BLKmode operands. -- What|Removed |Added Status|NEW |RESOLVED Known to fail|2.95.3 2.95.4 3.0.4 3.2.3 |2.95.3 2.95.4 3.0.4 3.2.3 |3.3.5 3.4.3 4.1.0 |3.3.5 3.4.3 4.0.0 Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20382
[Bug target/19923] [4.0/4.1 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
-- What|Removed |Added Summary|openssl is slower when |[4.0/4.1 Regression] openssl |compiled with gcc 4.0 than |is slower when compiled with |3.3 |gcc 4.0 than 3.3 Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug translation/21475] [4.0/4.1 regression] ICE with german locale in is used uninitialized warning
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-08
13:18 ---
Confirmed.
The problem can be demonstrated with the following code snippet:
===
int foo()
{
int i;
return i;
}
===
Compiling the above with -O -Wall and LC_ALL=C yields the warning
bug.c: In function 'foo':
bug.c:4: warning: 'i' is used uninitialized in this function
With LC_ALL=de_DE I get an ICE.
The following lines in the de.po file look suspicious:
#: tree-ssa.c:1379
msgid %H%qD is used uninitialized in this function
msgstr %J%qD wird in dieser Funktion uninitialisiert verwendet
Looks like we want %H%qD instead of %J%qD in the translation.
This affects the 4.0 branch and mainline.
--
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||diagnostic, ice-on-valid-
||code
Last reconfirmed|-00-00 00:00:00 |2005-06-08 13:18:42
date||
Summary|gcc fails with german |[4.0/4.1 regression] ICE
|locale, builts fine with|with german locale in is
|LC_ALL=C |used uninitialized warning
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21475
[Bug libstdc++/21951] [4.0 only] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 13:20 --- Note Mark has said in the past (and in a private mail which was supposed to be a public one too) that warnings cannot cause this to be a rejects valid. -- What|Removed |Added Keywords||diagnostic Summary|[gcc-4.0 regression,|[4.0 only] |rejects-valid] |std::vector.reserve() |std::vector.reserve() |unusable with -Werror -Wall |unusable with -Werror -Wall |-O -fno-exceptions |-O -fno-exceptions | Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug translation/21475] [4.0/4.1 regression] ICE with german locale in is used uninitialized warning
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-08 13:22 --- It's a dupe. *** This bug has been marked as a duplicate of 21364 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21475
[Bug translation/21364] [translation] %J in translation instead of %H causes ICE in de.po
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-08 13:22 --- *** Bug 21475 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||hanno at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
[Bug translation/21475] [4.0/4.1 regression] ICE with german locale in is used uninitialized warning
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 13:22 --- *** This bug has been marked as a duplicate of 21364 *** *** This bug has been marked as a duplicate of 21364 *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21475
[Bug libfortran/21950] All gfortran execution tests fail on Tru64 UNIX V4.0F: scalbn unresolved
-- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21950
[Bug translation/21567] Segmentation fault of the compiler when compiling
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-08 13:27 --- The original error message reads: bug.c: In function 'aie_sql_meta_create_index': bug.c:25: warning: 'tableid' is used uninitialized in this function bug.c: In function 'main': bug.c:25: warning: 'tableid' is used uninitialized in this function So this bug is a dupe of PR 21364. *** This bug has been marked as a duplicate of 21364 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21567
[Bug translation/21364] [translation] %J in translation instead of %H causes ICE in de.po
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 13:22 --- *** Bug 21475 has been marked as a duplicate of this bug. *** --- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-08 13:27 --- *** Bug 21567 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||alexander_herrmann at yahoo ||dot com dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
[Bug libfortran/21950] All gfortran execution tests fail on Tru64 UNIX V4.0F: scalbn unresolved
--- Additional Comments From ro at techfak dot uni-bielefeld dot de 2005-06-08 13:34 --- Subject: Re: All gfortran execution tests fail on Tru64 UNIX V4.0F: scalbn unresolved The same problem exists on IRIX 6.5.10 (once a patch for libfortran/15266, to be submitted after testing is complete, goes in) and most likely IRIX 5.3, too. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21950
[Bug translation/21364] [4.0/4.1 regression] [translation] %J in translation instead of %H causes ICE in de.po
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-08 13:36 --- Mark, I think this bug is a serious regression, since it renders -Wall in conjunction with the german locale unusable. Could we please incorporate the trivial fix in GCC 4.0.1 even if the new de.po file doesn't arrive on time? -- What|Removed |Added CC||mark at codesourcery dot com Keywords||diagnostic, ice-on-valid- ||code Summary|[translation] %J in |[4.0/4.1 regression] |translation instead of %H |[translation] %J in |causes ICE in de.po |translation instead of %H ||causes ICE in de.po Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
[Bug translation/21364] [4.0/4.1 regression] [translation] %J in translation instead of %H causes ICE in de.po
--- Additional Comments From joseph at codesourcery dot com 2005-06-08 13:44 --- Subject: Re: [4.0/4.1 regression] [translation] %J in translation instead of %H causes ICE in de.po On Wed, 8 Jun 2005, reichelt at gcc dot gnu dot org wrote: Mark, I think this bug is a serious regression, since it renders -Wall in conjunction with the german locale unusable. Could we please incorporate the trivial fix in GCC 4.0.1 even if the new de.po file doesn't arrive on time? I thought Jakub's changes and gcc.pot regeneration had got in in time for 4.0.1-rc1? Which means that when I submit the 4.0.1-rc1 .pot files to the TP they will automerge the .po files and mark the problem translations fuzzy, and the merged .po files will be in 4.0.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
[Bug libstdc++/21951] [4.0 only] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
--- Additional Comments From dank at kegel dot com 2005-06-08 13:57 --- It sure as hell is for those shops that require -Werror. But ok, I'll be happy if it's fixed for 4.0.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug libstdc++/21951] [4.0 only] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
--- Additional Comments From veksler at il dot ibm dot com 2005-06-08 14:11 --- (In reply to comment #6) Note Mark has said in the past (and in a private mail which was supposed to be a public one too) that warnings cannot cause this to be a rejects valid. For the same reason, PR 21183 should be reopened or merged with this PR: When compiling a C++ program with -Wall, I get the following compiler warning /usr/local/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_uninitialized.h:113: warning: control may reach end of non-void function '_ForwardIterator std::__uninitialized_copy_aux(_InputIterator, _InputIterator, ... The problem seems to be in __uninitialized_copy_aux() in stl_uninitialized.h The catch statement block beginning on line 89 merely exits the routine without actually returning a value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug c++/21960] New: Incorrect Syntax NOT rejected
Hi,
The code snippet below contains a syntax error.
The line i = 4, is termited by a , instead of a ;, but it still compiles
fine. Even the result of the compilation is correct.
I expected the Parse error before ... here, but the compiler doesn't even
give a warning.
If the line printf is removed, the compiler give the error message I
expected. Also when the line would be int i = 4, the error is given.
I hope you have enough information now.
Regards,
Eric Zuur.
Code snipet:
#include stdio.h
int main()
{
int i;
i = 4,
printf(int=%d\n, i);
return (i);
}
Compiler version and OS information:
[EMAIL PROTECTED] g++ -v -save-temps test.cpp
Reading specs from /apps/oss/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs
gcc version 2.95.3 20010315 (release)
/apps/oss/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/cpp0 -lang-c++ -v -D__GNUC__=2 -
D__GNUG__=2 -D__GNUC_MINOR_
_=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -
D__i386__ -D__linux__ -D__unix
-D__linux -Asystem(posix) -D__EXCEPTIONS -Acpu(i386) -Amachine(i386) -Di386 -
D__i386 -D__i386__ -Di686 -Dp
entiumpro -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ test.cpp test.ii
GNU CPP version 2.95.3 20010315 (release) (i386 Linux/ELF)
#include ... search starts here:
#include ... search starts here:
/apps/oss/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../include/g++-3
/usr/local/include
/apps/oss/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/../../../../i686-pc-linux-
gnu/include
/apps/oss/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
End of omitted list.
/apps/oss/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/cc1plus test.ii -quiet -
dumpbase test.cc -version -o test.s
GNU C++ version 2.95.3 20010315 (release) (i686-pc-linux-gnu) compiled by GNU C
version 2.95.3 20010315 (re
lease).
as -V -Qy -o test.o test.s
GNU assembler version 2.11.90.0.8 (i386-redhat-linux) using BFD version
2.11.90.0.8
/apps/oss/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/collect2 -m elf_i386 -dynamic-
linker /lib/ld-linux.so.2 /us
r/lib/crt1.o /usr/lib/crti.o /apps/oss/lib/gcc-lib/i686-pc-linux-
gnu/2.95.3/crtbegin.o -L/apps/oss/lib/gcc-
lib/i686-pc-linux-gnu/2.95.3 -L/apps/oss/lib test.o -lstdc++ -lm -lgcc -lc -
lgcc /apps/oss/lib/gcc-lib/i686
-pc-linux-gnu/2.95.3/crtend.o /usr/lib/crtn.o
--
Summary: Incorrect Syntax NOT rejected
Product: gcc
Version: 3.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric at ez-soft dot demon dot nl
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: Linux 2.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21960
[Bug c++/21960] Incorrect Syntax NOT rejected
--- Additional Comments From eric at ez-soft dot demon dot nl 2005-06-08 14:17 --- Now the compiler version and OS information of the v3.3.1 compiler. Previous post gave the compiler version and OS information of the v2.95.3 compiler. Reading specs from /nfs/rvl/users/nlezu0/usr/local/lib/gcc-lib/i686-pc-linux- gnu/3.3.1/specs Configured with: ./configure --prefix=/nfs/rvl/users/nlezu0/usr/local Thread model: posix gcc version 3.3.1 /nfs/rvl/users/nlezu0/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/cc1plus - E -D__GNUG__=3 -quiet -v -D__GNUC__=3 -D__GNUC_MINOR__=3 - D__GNUC_PATCHLEVEL__=1 -D_GNU_SOURCE test.cpp test.ii ignoring nonexistent directory /nfs/rvl/users/nlezu0/usr/local/i686-pc-linux- gnu/include #include ... search starts here: #include ... search starts here: /nfs/rvl/users/nlezu0/usr/local/include/c++/3.3.1 /nfs/rvl/users/nlezu0/usr/local/include/c++/3.3.1/i686-pc-linux-gnu /nfs/rvl/users/nlezu0/usr/local/include/c++/3.3.1/backward /usr/local/include /nfs/rvl/users/nlezu0/usr/local/include /nfs/rvl/users/nlezu0/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/include /usr/include End of search list. /nfs/rvl/users/nlezu0/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/cc1plus - fpreprocessed test.ii -quiet -dumpbase test.cpp -auxbase test -version -o test.s GNU C++ version 3.3.1 (i686-pc-linux-gnu) compiled by GNU C version 2.95.3 20010315 (release). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 as --traditional-format -V -Qy -o test.o test.s GNU assembler version 2.11.90.0.8 (i386-redhat-linux) using BFD version 2.11.90.0.8 /nfs/rvl/users/nlezu0/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/collect2 - m elf_i386 -dynamic-linker /lib/ld- linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /nfs/rvl/users/nlezu0/usr/local/lib/g cc-lib/i686-pc-linux-gnu/3.3.1/crtbegin.o - L/nfs/rvl/users/nlezu0/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1 - L/nfs/rvl/users/nlezu0/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../.. test.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s - lgcc /nfs/rvl/users/nlezu0/usr/local/lib/gcc-lib/i686-pc-linux- gnu/3.3.1/crtend.o /usr/lib/crtn.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21960
[Bug c++/21960] Incorrect Syntax NOT rejected
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 14:18 --- THis is valid code as comma is an operator. a, b; is valid for all expressions, a and b. Since return is a statement and not an expression we get an error for that case. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21960
[Bug fortran/21961] New: PURE function in INTERFACE block not resolved as being a function
A PURE function that is part of an INTERFACE block is not resolved as being a function. Gfortran gives the following warning for the code attached at the end of this description: module_procedure-1.f90: In function 'show': module_procedure-1.f90:30: warning: unused variable 'test' I originally tested this using GNU Fortran 95 (GCC 4.1.0 20050602 (experimental)) and retested it using GNU Fortran 95 (GCC 4.1.0 20050608 (experimental)). --- MODULE procedures PUBLIC :: test PRIVATE :: test1,test2 INTERFACE test MODULE PROCEDURE test1,test2 END INTERFACE test CONTAINS PURE FUNCTION test1 (x) RESULT(r) REAL(KIND(0.0d0)), INTENT(IN) :: x REAL(KIND(0.0d0)) :: r r=x+1.0d0 END FUNCTION test1 PURE FUNCTION test2 (x) RESULT(r) REAL(KIND(0.0d0)), DIMENSION(:), INTENT(IN) :: x REAL(KIND(0.0d0)), DIMENSION(SIZE(x)):: r FORALL (i=1:SIZE(x)) r(i)=x(i)+1.0d0 END FORALL END FUNCTION test2 END MODULE procedures MODULE actions USE procedures CONTAINS SUBROUTINE show (x) REAL(KIND(0.0d0)), DIMENSION(:):: x REAL(KIND(0.0d0)), DIMENSION(SIZE(x)) :: d d=test (x) WRITE (*,'(F8.6)') d END SUBROUTINE show END MODULE actions PROGRAM module_procedure_1 USE actions REAL(KIND(0.0d0)), DIMENSION(2) :: x x=(/ 1.0d0,0.0d0 /) CALL show (x) END PROGRAM module_procedure_1 -- Summary: PURE function in INTERFACE block not resolved as being a function Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mhesseli at caltech dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.9.0 GCC host triplet: powerpc-apple-darwin7.9.0 GCC target triplet: powerpc-apple-darwin7.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21961
[Bug libstdc++/21951] [4.0 only] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
--- Additional Comments From veksler at il dot ibm dot com 2005-06-08
14:43 ---
(In reply to comment #7)
It sure as hell is for those shops that require -Werror.
But ok, I'll be happy if it's fixed for 4.0.2.
I think that your argument (as phrased) does not hold.
Maybe you meant It sure as hell is for those shops that require -Werror,
in this particular instance.
(Pardon my language, I just quoted the original ;-)
Consider:
1. 1: int main()
2: {
3: int a;
4: never_return(); // the halting problem
5: return a; // Uninitialized variable?
6: }
This is perfectly valid code and well defined, yet -Wall -Werror
will reject it. No compiler will ever be able to determine if
line 5 is ever reached.
2. 1: int main()
2: {
3:int a;
4:if(foo())
5: a= bar();
6:if(foo())
7: return a; // Uninitialized variable?
8:return 0;
9: }
Again, no compiler will be able to prove that a nontrivial foo() does
not change over time (unless declared const/pure/whatever).
And as a result, -Wall -Werror will reject valid code.
In both examples, the user has a simple work-around, initialize 'a'.
Adding initialization will make the code more stable, as foo() is
no longer constrained to be const/pure (forgive me for not remembering if
it is called pure or const).
In contrast (as mentioned in comment #4), this PR and PR 21183 do not
give the user the tools to shut this specific diagnostic instance up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug rtl-optimization/10588] [PPC] i==0||j==0 should use cntlzw and srawi
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-08 14:46 --- Subject: Bug 10588 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-08 14:46:14 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.md Log message: * config/rs6000/rs6000.md (call_indirect_nonlocal_aix32): Prefer CTR to LR. (call_indirect_nonlocal_aix64): Same. (call_value_indirect_nonlocal_aix32): Same. (call_value_indirect_nonlocal_aix64): Same. PR target/10588 (eq): Use CLZ splitter for compare with zero. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9091r2=2.9092 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gccr1=1.375r2=1.376 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10588
[Bug c/21962] New: [bogus warning] format '%012llx' expects type X, but argument has type X
extern void print(const char *my_format, ...)
__attribute__((format(printf, 1, 2)));
typedef struct {
unsigned long long family:8, id:48, crc:8;
} bar;
void foo(bar *x)
{
print(%012llx\n, x-id);
}
$ gcc testcase.c -c -Wall
testcase.c: In function 'foo':
testcase.c:9: warning: format '%012llx' expects type 'long long unsigned int',
but argument 2 has type 'long long unsigned int'
$ gcc -v
Reading specs from /usr/lib/gcc/i686-pld-linux/4.0.1/specs
Target: i686-pld-linux
Configured with: ../configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-languages=c,c++,f95,objc,ada,java --enable-c99 --enable-long-long
--disable-multilib --enable-nls --with-gnu-as --with-gnu-ld
--with-demangler-in-ld --with-system-zlib --with-slibdir=/lib --without-x
--enable-cmath --enable-libgcj --enable-libgcj-multifile
--enable-libgcj-database --enable-gtk-cairo i686-pld-linux
Thread model: posix
gcc version 4.0.1 20050521 (prerelease) (PLD Linux)
--
Summary: [bogus warning] format '%012llx' expects type X, but
argument has type X
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pld-linux
GCC host triplet: i686-pld-linux
GCC target triplet: i686-pld-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21962
[Bug regression/21963] New: ICE (Segmentation fault) with -m64
Compiling this code: = # 1 prob.F # 0 built-in # 1 command line # 1 prob.F SUBROUTINE XSHIF2 (A,WORK) COMMON /CNETIN/ IMA,JMA,KMA 1 ,IMAP2,JMAP2,KMAP2 2 ,IKBL0,IKBL2,JKBL2,IJKBL0,IJKBL2 3 ,JD2,JD2P1,IPOISS,ODJMA,ODIMA COMMON /CRUNIN/ IUFI,IULA,IPFI,IPLA 1 ,JVFI,JVLA,JPFI,JPLA 2 ,KWFI,KWLA,KPFI,KPLA 3 ,IUFIM1,IULAP1,IPFIM1,IPLAP1 4 ,JVFIM1,JVLAP1,JPFIM1,JPLAP1 5 ,KWFIM1,KWLAP1,KPFIM1,KPLAP1 6 ,JKPFI,JKWFI C DIMENSION A(*),WORK(*) C N = IMA*JMAP2*KMA+1 DO 10 I=IPLA,IPFI,-1 LI = (I-1)*JKBL2 DO 20 K=KPLA,KPFI,-1 LK = (K-1)*JMAP2 LIK = LI + LK N = N - 2 DO 30 J=JPLA,JPFI,-1 N = N - 1 WORK(J) = A(N) 30 CONTINUE DO 31 J=JPLA,JPFI,-1 LIJK= LIK + J A(LIJK) = WORK(J) 31 CONTINUE 20 CONTINUE 10 CONTINUE C C END OF SUBROUTINE X S H I F 2 C RETURN END = with: = gfortran -Wall -Wextra -ffixed-line-length-0 -O1 -m64 -pedantic -c prob.F = results in: = prob.F: In function #8216;xshif2#8217;: prob.F:1: internal compiler error: Segmentation fault = Output of gfortran -v: = Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/home/vici --enable-languages=f95 : (reconfigured) ./configure --prefix=/home/vici --enable-languages=c,f95 --no-create --no-recursion : (reconfigured) ./configure --prefix=/home/vici --enable-languages=c,f95 --enable-mapped-location : (reconfigured) ./configure --prefix=/home/vici --enable-mapped-location --enable-languages=c,f95 --no-create --no-recursion : (reconfigured) ./configure --prefix=/home/vici --enable-mapped-location --enable-languages=c,f95 --no-create --no-recursion : (reconfigured) ./configure --prefix=/home/vici --enable-mapped-location --enable-languages=c,f95 --no-create --no-recursion : (reconfigured) ./configure --prefix=/home/vici --enable-mapped-location --enable-languages=c,f95 --no-create --no-recursion Thread model: posix gcc version 4.1.0 20050608 (experimental) = Using -m32 works. The problem does not occur on 20050605. Victor -- Summary: ICE (Segmentation fault) with -m64 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fischer at td dot mw dot tum dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21963
[Bug regression/21963] ICE (Segmentation fault) with -m64
-- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21963
[Bug c/21962] 4.0/4.1 Regression] ] format '%012llx' expects type X, but argument has type X
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 15:04 --- : Search converges between 2004-07-08-trunk (#482) and 2004-07-09-trunk (#483). Confirmed, I think this is related to the bitfield changes. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-06-08 15:04:56 date|| Summary|[bogus warning] format |4.0/4.1 Regression] ] format |'%012llx' expects type X, |'%012llx' expects type X, |but argument has type X |but argument has type X http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21962
[Bug tree-optimization/21963] [4.1 Regression] ICE (Segmentation fault) with -m64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 15:27 --- Confirmed, backtrace: #0 0x000c5364 in is_gimple_variable (t=0x0) at ../../gcc/tree-gimple.c:239 #1 0x000c5908 in is_gimple_val (t=0x0) at ../../gcc/tree-gimple.c:353 #2 0x000e5334 in force_gimple_operand (expr=0x0, stmts=0xb2c8, simple=0 '\0', var=0x1e7b4fc) at ../../gcc/gimplify.c:4727 #3 0x001f00fc in rewrite_use_nonlinear_expr (data=0xb490, use=0x1d0a350, cand=0x1d0a860) at ../../gcc/tree-ssa-loop-ivopts.c:5359 #4 0x001f1c04 in rewrite_use (data=0xb490, use=0x1d0a350, cand=0x1d0a860) at ../../gcc/tree- ssa-loop-ivopts.c:5723 #5 0x001f1d14 in rewrite_uses (data=0xb490) at ../../gcc/tree-ssa-loop-ivopts.c:5759 #6 0x001f258c in tree_ssa_iv_optimize_loop (data=0xb490, loop=0x1d09560) at ../../gcc/tree- ssa-loop-ivopts.c:5935 #7 0x001f2694 in tree_ssa_iv_optimize (loops=0x1d014d0) at ../../gcc/tree-ssa-loop-ivopts.c:5972 #8 0x001a4aac in tree_ssa_loop_ivopts () at ../../gcc/tree-ssa-loop.c:388 #9 0x000c3750 in execute_one_pass (pass=0x96b61c) at ../../gcc/tree-optimize.c:627 -- What|Removed |Added CC||rakdver at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Component|regression |tree-optimization Ever Confirmed||1 GCC build triplet|x86_64-linux-gnu| GCC host triplet|x86_64-linux-gnu| Last reconfirmed|-00-00 00:00:00 |2005-06-08 15:27:47 date|| Summary|ICE (Segmentation fault)|[4.1 Regression] ICE |with -m64 |(Segmentation fault) with - ||m64 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21963
[Bug rtl-optimization/10588] [PPC] i==0||j==0 should use cntlzw and srawi
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 15:46 --- On the mainline we get the following now: _h: cmpwi cr7,r3,0 li r3,1 beqlr- cr7 cntlzw r3,r4 srwi r3,r3,5 blr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10588
[Bug target/20666] SPARC builtins should be folded if possible
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-08 16:03 --- Subject: Bug 20666 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-08 16:03:31 Modified files: gcc: ChangeLog gcc/config/sparc: sparc.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.target/sparc: fexpand-2.c fpmerge-2.c fpmul-2.c noresult.c pdist-2.c pdist-3.c Log message: 2005-06-08 James A. Morrison [EMAIL PROTECTED] PR target/20666 * config/sparc/sparc.c (sparc_fold_builtin): New function (sparc_vis_mul8x16): New function. (sparc_handle_vis_mul8x16): New function. (TARGET_FOLD_BUILTIN): Define to sparc_fold_builtin. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9092r2=2.9093 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.c.diff?cvsroot=gccr1=1.376r2=1.377 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5615r2=1.5616 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/sparc/fexpand-2.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/sparc/fpmerge-2.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/sparc/fpmul-2.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/sparc/noresult.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/sparc/pdist-2.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/sparc/pdist-3.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20666
[Bug c/21962] 4.0/4.1 Regression] ] format '%012llx' expects type X, but argument has type X
--- Additional Comments From joseph at codesourcery dot com 2005-06-08
16:32 ---
Subject: Re: New: [bogus warning] format '%012llx' expects type
X, but argument has type X
On Wed, 8 Jun 2005, pluto at agmk dot net wrote:
extern void print(const char *my_format, ...)
__attribute__((format(printf, 1, 2)));
typedef struct {
unsigned long long family:8, id:48, crc:8;
} bar;
void foo(bar *x)
{
print(%012llx\n, x-id);
}
$ gcc testcase.c -c -Wall
testcase.c: In function 'foo':
testcase.c:9: warning: format '%012llx' expects type 'long long unsigned int',
but argument 2 has type 'long long unsigned int'
The problem here is the text of the diagnostic, not the fact of the
diagnostic - the argument type is really unsigned long long:48 which is
not promoted to plain unsigned long long, so there is indeed undefined
behavior on execution. I.e., pp_c_type_specifier where it does
if (TYPE_NAME (t))
t = TYPE_NAME (t);
else
t = c_common_type_for_mode (TYPE_MODE (t), TYPE_UNSIGNED (t));
pp_c_type_specifier (pp, t);
should check for the case of integer types with precision smaller than
that of the mode and display them specially.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21962
[Bug translation/21364] [4.0/4.1 regression] [translation] %J in translation instead of %H causes ICE in de.po
--- Additional Comments From mark at codesourcery dot com 2005-06-08 17:01 --- Subject: Re: [4.0/4.1 regression] [translation] %J in translation instead of %H causes ICE in de.po joseph at codesourcery dot com wrote: --- Additional Comments From joseph at codesourcery dot com 2005-06-08 13:44 --- Subject: Re: [4.0/4.1 regression] [translation] %J in translation instead of %H causes ICE in de.po On Wed, 8 Jun 2005, reichelt at gcc dot gnu dot org wrote: Mark, I think this bug is a serious regression, since it renders -Wall in conjunction with the german locale unusable. Could we please incorporate the trivial fix in GCC 4.0.1 even if the new de.po file doesn't arrive on time? I thought Jakub's changes and gcc.pot regeneration had got in in time for 4.0.1-rc1? Which means that when I submit the 4.0.1-rc1 .pot files to the TP they will automerge the .po files and mark the problem translations fuzzy, and the merged .po files will be in 4.0.1. I certainly agree that it would be good to fix this for 4.0.1 and that the fix seems simple. However, I don't understand yet whether there is still a problem, given Joseph's comment. I'm on the CC: list for this PR, so please direct further comments there; I'll pay attention. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
[Bug translation/21364] [4.0/4.1 regression] [translation] %J in translation instead of %H causes ICE in de.po
--- Additional Comments From jakub at gcc dot gnu dot org 2005-06-08 17:08 --- There is a problem until the po files from the TP robot (assuming the robot is running gettext 0.14.5) are committed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
[Bug c/21964] New: broken tail call at -O2 or more
Optimisations seem to cause the post increment in the recursive function call to
foo() to pass the increased value to the function.
Expected output, and output when compiled without -O2:
0
0
0
0
...
Actual output with -O2 or -O3 or...:
0
1
2
3
...
#include stdio.h
void foo(int n);
int main(void) {
foo(0);
return 0;
}
void foo(int n) {
printf(%d\n, n);
foo(n++);
}
--
Summary: broken tail call at -O2 or more
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ben at 0x539 dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21964
[Bug translation/21364] [4.0/4.1 regression] [translation] %J in translation instead of %H causes ICE in de.po
--- Additional Comments From mark at codesourcery dot com 2005-06-08 17:23 --- Subject: Re: [4.0/4.1 regression] [translation] %J in translation instead of %H causes ICE in de.po jakub at gcc dot gnu dot org wrote: --- Additional Comments From jakub at gcc dot gnu dot org 2005-06-08 17:08 --- There is a problem until the po files from the TP robot (assuming the robot is running gettext 0.14.5) are committed. OK. I shall bear this in mind before actually making the release, then; hopefully the new files will be in before that point. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
[Bug libstdc++/21955] std::stringbuf vs. in_avail
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-08 17:29 --- Subject: Bug 21955 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-08 17:29:45 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/bits: fstream.tcc libstdc++-v3/include/std: std_sstream.h libstdc++-v3/testsuite/27_io/basic_stringbuf/in_avail/char: 1.cc libstdc++-v3/testsuite/27_io/basic_stringbuf/in_avail/wchar_t: 1.cc libstdc++-v3/testsuite/27_io/basic_stringbuf/str/char: 1.cc libstdc++-v3/testsuite/27_io/basic_stringbuf/str/wchar_t: 1.cc Added files: libstdc++-v3/testsuite/27_io/basic_filebuf/in_avail/char: 9701-3.cc libstdc++-v3/testsuite/27_io/basic_streambuf/in_avail/char: 1.cc libstdc++-v3/testsuite/27_io/basic_streambuf/in_avail/wchar_t: 1.cc libstdc++-v3/testsuite/27_io/basic_stringbuf/in_avail/char: 21955.cc Removed files: libstdc++-v3/testsuite/27_io/basic_streambuf/in_avail/char: 9701-3.cc libstdc++-v3/testsuite/27_io/basic_streambuf/in_avail/wchar_t: 9701-3.cc Log message: 2005-06-08 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/21955 * include/std/std_sstream.h (basic_stringbuf::showmanyc): Add. Remove unnecessary this-_M_mode decoration. * include/bits/fstream.tcc: Adjust line spacing. * testsuite/27_io/basic_streambuf/in_avail/char/1.cc: New, test base class behavior. * testsuite/27_io/basic_streambuf/in_avail/wchar_t/1.cc: Same. * testsuite/27_io/basic_stringbuf/in_avail/char/21955.cc: New. * testsuite/27_io/basic_stringbuf/in_avail/char/1.cc: Match filebuf behavior. * testsuite/27_io/basic_stringbuf/in_avail/wchar_t/1.cc: Same. * testsuite/27_io/basic_stringbuf/str/wchar_t/1.cc: Same. * testsuite/27_io/basic_stringbuf/str/char/1.cc: Same. * testsuite/27_io/basic_streambuf/in_avail/char/9701-3.cc: Move... * testsuite/27_io/basic_filebuf/in_avail/char/9701-3.cc: ...here. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gccr1=1.3036r2=1.3037 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/fstream.tcc.diff?cvsroot=gccr1=1.130r2=1.131 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/std/std_sstream.h.diff?cvsroot=gccr1=1.41r2=1.42 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_filebuf/in_avail/char/9701-3.cc.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_streambuf/in_avail/char/1.cc.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_streambuf/in_avail/char/9701-3.cc.diff?cvsroot=gccr1=1.2r2=NONE http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_streambuf/in_avail/wchar_t/1.cc.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_streambuf/in_avail/wchar_t/9701-3.cc.diff?cvsroot=gccr1=1.1r2=NONE http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_stringbuf/in_avail/char/21955.cc.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_stringbuf/in_avail/char/1.cc.diff?cvsroot=gccr1=1.3r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_stringbuf/in_avail/wchar_t/1.cc.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_stringbuf/str/char/1.cc.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/27_io/basic_stringbuf/str/wchar_t/1.cc.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21955
[Bug fortran/21480] trivial reshape operation gives erroneous results
--- Additional Comments From tobi at gcc dot gnu dot org 2005-06-08 17:32 --- Reopened, the bug is still present, and apparently completely unrelated to PR21127. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Keywords||wrong-code Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21480
[Bug c/21965] New: Openssl segfaults when compiled with gcc 4.0.0 on solaris 9
Running openssl 0.9.7g (this is the newest production version) with no arguments segfaults in lh_strhash when compiled with gcc 4.0.0 on Solaris 9, but runs fine when compiled with gcc-3.2.2. -- Summary: Openssl segfaults when compiled with gcc 4.0.0 on solaris 9 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ftlofaro at yahoo dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.9 GCC host triplet: sparc-sun-solaris2.9 GCC target triplet: sparc-sun-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21965
[Bug c/21965] Openssl segfaults when compiled with gcc 4.0.0 on solaris 9
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 17:42 --- Are you sure that this is a GCC bug, please add the preprocessed source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21965
[Bug c/21965] Openssl segfaults when compiled with gcc 4.0.0 on solaris 9
--- Additional Comments From ftlofaro at yahoo dot com 2005-06-08 17:48 --- Created an attachment (id=9046) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9046action=view) C preprocessor output This is the C preprocessor output of lhash.c, the file with the offending function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21965
[Bug middle-end/21965] Openssl segfaults when compiled with gcc 4.0.0 on solaris 9
-- What|Removed |Added Component|c |middle-end Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21965
[Bug tree-optimization/19768] [4.0 Regression] ICE: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 18:03 --- (In reply to comment #14) Michael could you revert it, I have no time to do so today, I have exams to work on all day today. I reverted it after getting approval from Mark. So this should be fixed again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19768
[Bug tree-optimization/19768] [4.0 Regression] ICE: SSA_NAME_OCCURS_IN_ABNORMAL_PHI should be set
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-08 18:04 --- Subject: Bug 19768 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-06-08 18:04:19 Modified files: gcc: ChangeLog tree-ssa-dse.c Log message: 2005-06-08 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/19768 * tree-ssa-dse.c: Revert accidental committed patch. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.283r2=2.7592.2.284 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-dse.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.17.4.1r2=2.17.4.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19768
[Bug middle-end/21964] broken tail call at -O2 or more
-- What|Removed |Added Component|c |middle-end Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21964
[Bug fortran/21480] trivial reshape operation gives erroneous results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 18:06 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-08 18:06:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21480
[Bug middle-end/21964] [3.4 Regression] broken tail call at -O2 or more
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 18:13 --- Confirmed, only a regression in 3.4.x. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||3.0.4 3.4.0 Known to work||4.0.0 4.1.0 2.95.3 Last reconfirmed|-00-00 00:00:00 |2005-06-08 18:13:50 date|| Summary|broken tail call at -O2 or |[3.4 Regression] broken tail |more|call at -O2 or more Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21964
[Bug tree-optimization/21963] [4.1 Regression] ICE (Segmentation fault) with -m64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 18:36 --- This ICE also shows up in SPEC on x86_64. -- What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21963
[Bug tree-optimization/21966] New: ICE in verify_ssa building 64-bit zlib on IRIX 6
Bootstrapping current mainline on IRIX 6.5 with --enable-libgcj fails building the 64-bit zlib: /.vol/gcc/obj/gcc-4.1.0-20050607/6.5-gcc-java/./gcc/xgcc -B/.vol/gcc/obj/gcc-4.1.0-20050607/6.5-gcc-java/./gcc/ -B/.vol/gcc/share/mips-sgi-irix6.5/bin/ -B/.vol/gcc/share/mips-sgi-irix6.5/lib/ -isystem /.vol/gcc/share/mips-sgi-irix6.5/include -isystem /.vol/gcc/share/mips-sgi-irix6.5/sys-include -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\zlib\ -DVERSION=\1.1.4\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_MEMCPY=1 -DHAVE_STRERROR=1 -DHAVE_UNISTD_H=1 -I. -I/.vol/gcc/src/gcc-dist/zlib -O2 -g -O2 -mabi=64 -c /.vol/gcc/src/gcc-dist/zlib/inffast.c -DPIC -o .libs/inffast.o /.vol/gcc/src/gcc-dist/zlib/inffast.c: In function 'inflate_fast': /.vol/gcc/src/gcc-dist/zlib/inffast.c:70: error: Definition in block 49 does not dominate use in block 47 for SSA_NAME: D.2252_580 in statement: D.2256_585 = D.2252_580 /[fl] 3; /.vol/gcc/src/gcc-dist/zlib/inffast.c:70: internal compiler error: verify_ssa failed. Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [inffast.lo] Error 1 Environment: System: IRIX64 columba 6.5 10120104 IP27 host: mips-sgi-irix6.5 build: mips-sgi-irix6.5 target: mips-sgi-irix6.5 configured with: /.vol/gcc/src/gcc-dist/configure --prefix=/.vol/gcc --with-local-prefix=/.vol/gcc --disable-nls --with-gnu-as --with-as=/homes/ro/bin/gas-2.15 --enable-libgcj --with-gmp-dir=/.vol/gcc/obj/gmp-4.1.3 --with-mpfr-dir=/.vol/gcc/obj/gmp-4.1.3/mpfr --disable-libmudflap How-To-Repeat: Bootstrap mainline as described above. --- Additional Comments From ro at techfak dot uni-bielefeld dot de 2005-06-08 18:38 --- Fix: The problem vanishes with -O0. -- Summary: ICE in verify_ssa building 64-bit zlib on IRIX 6 Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: mips-sgi-irix6.5 GCC host triplet: mips-sgi-irix6.5 GCC target triplet: mips-sgi-irix6.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21966
[Bug tree-optimization/21966] [4.1 Regression] ICE in verify_ssa building 64-bit zlib on IRIX 6
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 18:40 --- This was already fixed by: 2005-06-08 Zdenek Dvorak [EMAIL PROTECTED] * tree-ssa-loop-ivopts.c (rewrite_use_outer): Unshare the expression before emiting it. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||build, ice-on-valid-code Resolution||FIXED Summary|ICE in verify_ssa building |[4.1 Regression] ICE in |64-bit zlib on IRIX 6 |verify_ssa building 64-bit ||zlib on IRIX 6 Target Milestone|--- |4.1.0 Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21966
[Bug fortran/21480] trivial reshape operation gives erroneous results
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-08 18:59 --- Slightly reduced testcase: $ cat 21480.f90 program reshape_bug implicit none complex :: a(2), b(2) a = (/(1.0, -1.0), (2.0, -2.0)/) write(*,*) 'from' write(*,*) a b=reshape(a, shape(a)) write(*,*) 'to' write(*,*) b end program reshape_bug $ gfortran 21480.f90 $ ./a.out from ( 1.00, -1.00) ( 2.00, -2.00) to ( 1.00, -1.00) ( 2.8025969E-45, 2.200292) In other words, this has nothing to do with arrays starting at 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21480
[Bug libstdc++/21951] [4.0 only] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-08 19:16 --- This is a compiler bug. If they don't fix it in 4.0.x, then we'll have to work around it in libstdc++ 4.0 sources only. People have suggested a patch to add a dummy return. If that's posted, it seems to be perfectly acceptable to me. I suggest that be posted... -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug target/12455] Invalid ia64 unwind data when compiling with -pg
--- Additional Comments From rth at gcc dot gnu dot org 2005-06-08 19:38 --- Fixed here: http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00809.html -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12455
[Bug testsuite/21967] New: [4.1 Regression] gcc.dg/tree-ssa/loop-2.c and gcc.dg/tree-ssa/loop-4.c fail
FAIL: gcc.dg/tree-ssa/loop-2.c scan-tree-dump-times iter 0 has appeared on mainline on 20050608 on at least i686-pc-linux-gnu, hppa64-hpux and ia64-hpux (boht -milp32 and -mlp64). FAIL: gcc.dg/tree-ssa/loop-4.c scan-tree-dump-times iter 0 has appeared on mainline on 20050608 on at least i686-pc-linux-gnu and ia64-hpux (-milp32 only, though it was already failing on hppa64-hpux and -mlp64 ia64-hpux - bug 20605 - so it just isn't a new failure on those platforms). As the testcases changed in the relevant day it seems likely to be a testsuite problem, but it could also be a latent bug which was exposed between when the patch changing the testcases was tested and when it was applied. -- Summary: [4.1 Regression] gcc.dg/tree-ssa/loop-2.c and gcc.dg/tree-ssa/loop-4.c fail Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21967
[Bug target/21968] New: gcc.dg/tls/debug-1.c fails on ia64-hpux
FAIL: gcc.dg/tls/debug-1.c (test for excess errors) (a newly added test) appeared on mainline on 20050608. Not a regression; the test also ICEs with 3.4 and 4.0. This failure is with -milp32 only, not with -mlp64. The error is: tls/debug-1.c:4: internal compiler error: in ia64_output_dwarf_dtprel, at config/ia64/ia64.c:4167 -- Summary: gcc.dg/tls/debug-1.c fails on ia64-hpux Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: ia64-*-hpux11.* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21968
[Bug testsuite/21967] [4.1 Regression] gcc.dg/tree-ssa/loop-2.c and gcc.dg/tree-ssa/loop-4.c fail
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-08 20:07 --- Alos on powerpc-darwin, see http://gcc.gnu.org/ml/gcc-regression/2005-06/msg00035.html. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-08 20:07:23 date|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21967
[Bug middle-end/21969] New: ICE on float __attribute__((vector_size(2048)))
The following one line program gives an ICE typedef float vsf __attribute__((vector_size(2048))); x.c:1: internal compiler error: in round_up, at fold-const.c:11646 I reproduced this on IA64 and HPPA platforms and I do not think it is platform specific. -- Summary: ICE on float __attribute__((vector_size(2048))) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: ia64-hp-hpux11.23 GCC host triplet: ia64-hp-hpux11.23 GCC target triplet: ia64-hp-hpux11.23 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21969
[Bug fortran/21480] trivial reshape operation gives erroneous results
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/fortra ||n/2005-06/msg00172.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2005-06-08 18:06:36 |2005-06-08 20:20:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21480
[Bug middle-end/21965] Openssl segfaults when compiled with gcc 4.0.0 on solaris 9
-- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21965
[Bug debug/21889] Bad assembler output for Solaris TLS debug symbols
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-08 20:45 --- Subject: Bug 21889 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-06-08 20:44:58 Modified files: gcc: ChangeLog gcc/config/sparc: sol2-gas.h sol2.h Log message: PR target/21889 * config/sparc/sol2.h (ASM_OUTPUT_DWARF_DTPREL): Undefine. * config/sparc/sol2-gas.h (ASM_OUTPUT_DWARF_DTPREL): Redefine. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.284r2=2.7592.2.285 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sol2-gas.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.1r2=1.1.46.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sol2.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.69.8.1r2=1.69.8.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21889
[Bug debug/21889] Bad assembler output for Solaris TLS debug symbols
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-08 20:53 --- Subject: Bug 21889 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-06-08 20:52:36 Modified files: gcc: ChangeLog gcc/config/sparc: sol2-gas-bi.h sol2.h Log message: PR target/21889 * config/sparc/sol2.h (ASM_OUTPUT_DWARF_DTPREL): Undefine. * config/sparc/sol2-gas.h (ASM_OUTPUT_DWARF_DTPREL): Redefine. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.876r2=2.2326.2.877 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sol2-gas-bi.h.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.4r2=1.4.14.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sol2.h.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.57.4.4r2=1.57.4.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21889
[Bug debug/21889] Native Solaris assembler cannot grok DTP-relative debug symbols
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-06-08 20:56 --- See http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00478.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|Bad assembler output for|Native Solaris assembler |Solaris TLS debug symbols |cannot grok DTP-relative ||debug symbols Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21889
[Bug libgcj/18266] SIGSEGV in GC_register_finalizer_inner ()
--- Additional Comments From ovidr at users dot sourceforge dot net 2005-06-08 21:14 --- Since this bug seems a bit lost, I've been trying some things on my own without success. Can someone please explain: If referent is just a RawData pointer to some Object, how are its previous finalizers supposed to be found? How to append them along with the new finalizer in the correct order (order matters?) to GC_REGISTER_FINALIZER_NO_ORDER (GC_register_finalizer_inner(obj, fn, cd, ofn, ocd, mp)) which seems to be what is used in natObject.cc? The comments in this bug seem to suggest that there is some similar code somewhere that I could lift and hook into natReference.create, but all the code in natObject and String.intern finalization looks very different to my novice-gcj eyes since they don't seem to be working with some foreign object, nor with finalizers that aren't already locally stored in a struct. Secondly, is there any way to craft a testcase for this to know if it has been fixed? I don't fully understand why (based on comment #6) this would ever cause a crash, and waiting many days for the crash of my apps is a very tedious process. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18266
[Bug c/21970] New: Inline keyword causes computation to erroneously reduce to a constant
I have a function which evaluates the SHA-1 cryptographic hash function. It
takes as parameters the 160-bit state and 64 bytes to hash and produces an
output 160-bit state. When compiling at -O0, it is horrendously slow, but it
(as far as I know) produces correct behavior. For quick reference, a (brief)
function definition follows:
typedef unsigned long UINT32;
typedef struct
{
UINT32 a, b, c, d, e;
} SHA1_STATE;
void sha1(SHA1_STATE *pState, void const *pvBuf);
At -O1 and above, the SHA-1 function is reduced to the following code:
_sha1:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %eax
movl$0, (%eax)
movl$0, 4(%eax)
movl$0, 8(%eax)
movl$0, 12(%eax)
movl$0, 16(%eax)
popl%ebp
ret
Because this file is autogenerated, I generate function calls to do trivial
operations such as addition and rely on function inlining to preserve
performance. If these functions are not marked with the inline keyword, then
this bug does not trigger. Also, I tried removing roughly half of the code from
the function, and it cause the bug to no longer trigger. I removed all code
below line 316 and simply copied the final 5 keys from the key schedule (w75,
w76, w77, w78, w79) to the output state.
I have observed the same behavior on MinGW GCC versions 3.3.1 and 3.4.2. The
output of gcc -v for the version I am reporting against is as follows:
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: /var/tmp/portage/gcc-3.4.4/work/gcc-3.4.4/configure --enable-
version-specific-runtime-libs --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-
bin/3.4.4 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/include --
datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.4.4 --mandir=/usr/share/gcc-
data/i686-pc-linux-gnu/3.4.4/man --infodir=/usr/share/gcc-data/i686-pc-linux-
gnu/3.4.4/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-
gnu/3.4.4/include/g++-v3 --host=i686-pc-linux-gnu --disable-altivec --enable-
nls --without-included-gettext --with-system-zlib --disable-checking --disable-
werror --disable-libunwind-exceptions --disable-multilib --disable-libgcj --
enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-
__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 3.4.4 (Gentoo Hardened 3.4.4, ssp-3.4.4-1.0, pie-8.7.8)
--
Summary: Inline keyword causes computation to erroneously reduce
to a constant
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: para at cfl dot rr dot com
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=21970
[Bug c/21970] Inline keyword causes computation to erroneously reduce to a constant
--- Additional Comments From para at cfl dot rr dot com 2005-06-08 23:01 --- Created an attachment (id=9047) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9047action=view) The stand-alone source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21970
[Bug rtl-optimization/21970] Inline keyword causes computation to erroneously reduce to a constant
-- What|Removed |Added Component|c |rtl-optimization Keywords||wrong-code Known to work||4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21970
