[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 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
[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. |
[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 fortran/21915] Would like atanh etc. as intrinsics
--- Additional Comments From jvdelisle at verizon dot net 2005-06-08 05:26 --- We have sinh, cosh, tanh. I will work on the asinh, acosh, and atanh. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21915
[Bug rtl-optimization/21956] New: useless symbols in object files
Compile with -freorder-blocks-and-partition and you'll find 006b4a73 t .COLDE999 004026a0 t .HOTB0 These symbols are not removed by the assembler because they are not named properly. The partitioning code should be using either ASM_GENERATE_INTERNAL_LABEL or targetm.asm_out.internal_label or both. -- Summary: useless symbols in object files Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rth at gcc dot gnu dot org CC: ctice at apple dot com,gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21956
[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 05:06 --- Subject: Bug 21889 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-08 05:05:48 Modified files: gcc: ChangeLog config.gcc dwarf2out.c system.h target-def.h target.h gcc/config/frv : frv-protos.h frv.c frv.h gcc/config/i386: i386-protos.h i386.c i386.h gcc/config/ia64: ia64-protos.h ia64.c ia64.h gcc/config/rs6000: rs6000-protos.h rs6000.c rs6000.h gcc/config/s390: s390-protos.h s390.c s390.h gcc/config/sparc: sol2-gas.h sol2.h sparc-protos.h sparc.c sparc.h gcc/doc: tm.texi Log message: PR target/21889 * target.h (gcc_target) : New field output_dwarf_dtprel. * target-def.h (TARGET_ASM_OUTPUT_DWARF_DTPREL): New macro. (TARGET_ASM_OUT): Add it. * doc/tm.texi (Debugging Info): Document it. * dwarf2out.c (output_loc_operands) : Test it instead of ASM_OUTPUT_DWARF_DTPREL. (loc_descriptor_from_tree_1) : Likewise. * system.h: Poison ASM_OUTPUT_DWARF_DTPREL. * config/frv/frv-protos.h (frv_output_dwarf_dtprel): Delete. * config/frv/frv.c (frv_output_dwarf_dtprel): Make static and unused. (gen_inlined_tls_plt): Remove unused variable MEM. (TARGET_ASM_OUTPUT_DWARF_DTPREL): Define to frv_output_dwarf_dtprel. * config/frv/frv.h (ASM_OUTPUT_DWARF_DTPREL): Delete. * config/i386/i386-protos.h (i386_output_dwarf_dtprel): Delete. * config/i386/i386.c (i386_output_dwarf_dtprel): Make static and unused. (TARGET_ASM_OUTPUT_DWARF_DTPREL): Define to i386_output_dwarf_dtprel. * config/i386/i386.h (ASM_OUTPUT_DWARF_DTPREL): Delete. * config/ia64/ia64-protos.h (ia64_output_dwarf_dtprel): Delete. * config/ia64/ia64.c (ia64_output_dwarf_dtprel): Make static and unused. (TARGET_ASM_OUTPUT_DWARF_DTPREL): Define to ia64_output_dwarf_dtprel. * config/ia64/ia64.h (ASM_OUTPUT_DWARF_DTPREL): Delete. * config/rs6000/rs6000-protos.h (rs6000_output_dwarf_dtprel): Delete. * config/rs6000/rs6000.c (rs6000_output_dwarf_dtprel): Make static and unused. (TARGET_ASM_OUTPUT_DWARF_DTPREL): Define to rs6000_output_dwarf_dtprel * config/rs6000/rs6000.h (ASM_OUTPUT_DWARF_DTPREL): Delete. * config/s390/s390-protos.h (s390_output_dwarf_dtprel): Delete. * config/s390/s390.c (s390_output_dwarf_dtprel): Make static and unused. (TARGET_ASM_OUTPUT_DWARF_DTPREL): Define to s390_output_dwarf_dtprel. * config/s390/s390.h (ASM_OUTPUT_DWARF_DTPREL): Delete. * config/sparc/sol2-gas.h (TARGET_SUN_TLS): Define to 0. (TARGET_GNU_TLS): Define to 1. * config/sparc/sparc-protos.h (sparc_output_dwarf_dtprel): Delete. * config/sparc/sparc.c (sparc_output_dwarf_dtprel): Make static and unused. (TARGET_ASM_OUTPUT_DWARF_DTPREL): Define to sparc_output_dwarf_dtprel if TARGET_GNU_TLS only. * config/sparc/sparc.h (ASM_OUTPUT_DWARF_DTPREL): Delete. * config.gcc (sparc64-*-solaris2*): Include tm-dwarf2.h last. (sparc-*-solaris2*): Likewise on Solaris 7 and up. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9084&r2=2.9085 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config.gcc.diff?cvsroot=gcc&r1=1.548&r2=1.549 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gcc&r1=1.598&r2=1.599 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/system.h.diff?cvsroot=gcc&r1=1.257&r2=1.258 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/target-def.h.diff?cvsroot=gcc&r1=1.123&r2=1.124 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/target.h.diff?cvsroot=gcc&r1=1.135&r2=1.136 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/frv/frv-protos.h.diff?cvsroot=gcc&r1=1.26&r2=1.27 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/frv/frv.c.diff?cvsroot=gcc&r1=1.89&r2=1.90 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/frv/frv.h.diff?cvsroot=gcc&r1=1.64&r2=1.65 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386-protos.h.diff?cvsroot=gcc&r1=1.139&r2=1.140 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.825&r2=1.826 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.h.diff?cvsroot=gcc&r1=1.436&r2=1.437 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64-protos.h.diff?cvsroot=gcc&r1=1.72&r2=1.73 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&r1=1.370&r2=1.371 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.h.diff?cvsroot=gcc&r1=1.200&r2=1.201 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000-protos.h.diff?cvsroot=gcc&r1=1.100&r2=1.101 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/
[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 03:32 --- The problem with the hash table seems to be fixed in gcc 4.1, but not gcc 3.4 or 4.0. In gcc 4.1 hash_rtx is used for the implicit sets instead of the really dumb hash_set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097
[Bug target/18655] Incorrect data in .debug_frame section for PowerPC
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-08 02:45 --- Subject: Bug 18655 CVSROOT:/cvs/gcc Module name:gcc Branch: csl-3_4_3-linux-branch Changes by: [EMAIL PROTECTED] 2005-06-08 02:44:59 Modified files: . : ChangeLog.csl gcc: dwarf2out.c Log message: PR 18655 * dwarf2out.c (output_call_frame_info): Use DWARF2_FRAME_REG_OUT before outputting DWARF_FRAME_RETURN_COLUMN. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.csl.diff?cvsroot=gcc&only_with_tag=csl-3_4_3-linux-branch&r1=1.1.6.3&r2=1.1.6.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gcc&only_with_tag=csl-3_4_3-linux-branch&r1=1.461.2.12.2.1&r2=1.461.2.12.2.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18655
[Bug testsuite/21094] libmudflap C++ tests run even when C++ not configured
--- Additional Comments From giovannibajo at libero dot it 2005-06-08 01:52 --- Confirmed. -- What|Removed |Added CC||janis at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-08 01:52:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21094
[Bug target/20928] [4.0/4.1 regression] ICE: unrecognizable insns
--- Additional Comments From rth at gcc dot gnu dot org 2005-06-08 00:08 --- This patch trivially "fixes" the problem because the argument to legitimate_pic_address_disp_p is incorrect, and it will always return false. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20928
[Bug rtl-optimization/21528] [4.0 Regression] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From rth at gcc dot gnu dot org 2005-06-07 23:49 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug rtl-optimization/21528] [4.0 Regression] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-07 23:48 --- Subject: Bug 21528 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-06-07 23:48:31 Modified files: gcc: ChangeLog rtlanal.c Log message: PR rtl-opt/21528 * rtlanal.c (reg_overlap_mentioned_p) : Handle 'E' formats. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.282&r2=2.7592.2.283 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/rtlanal.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.211&r2=1.211.8.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug fortran/21902] ICE in build_array_type, at tree.c:4581
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-07 23:46 --- This seems to be a duplicate of our famous bug PR 15966. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21902
[Bug rtl-optimization/21528] [4.0 Regression] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-07 23:45 --- Subject: Bug 21528 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-07 23:45:09 Modified files: gcc: ChangeLog rtlanal.c Log message: PR rtl-opt/21528 * rtlanal.c (reg_overlap_mentioned_p) : Handle 'E' formats. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9078&r2=2.9079 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/rtlanal.c.diff?cvsroot=gcc&r1=1.215&r2=1.216 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug libstdc++/21951] [gcc-4.0 regression, rejects-valid] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
--- Additional Comments From bangerth at dealii dot org 2005-06-07 23:28 --- I concur with the last post -- a dummy return at the end would solve the problem and seems like an acceptable solution for a release branch. W. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Component|c++ |libstdc++ Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug middle-end/21939] [3.4 Regression] corrupted memory with deque of >63 items
--- Additional Comments From fuzzypoint at yahoo dot com 2005-06-07 22:19
---
(In reply to comment #5)
> Yup, segfaults for 64 on x86-64 too with 3.4.5pre:
>
> Program received signal SIGSEGV, Segmentation fault.
> main (argc=-1781549440, argv=0x0) at stl_deque.h:134
> 134 { return *_M_cur; }
>
I'm having similar trouble in x86_64 as well.
Tried the above sample on x86_64 and can confirm.
I modified the program above
a bit and it seems like deque::operator++ is at fault (or badly compiled).
First the modified sample program
#include
#include
#include
using std::deque;
using std::auto_ptr;
static char c = 0;
struct A { long x; char y; A() : x(0),y(c++) {} };
auto_ptr > foo(int l){
auto_ptr > d(new deque);
for (int i=0; ipush_back(A());
return d;
}
struct v { void *a, *b, *c, *d; };
void foo();
int main(int argc, char **argv)
{
auto_ptr > d = foo(atoi(argv[1]));
A a;
std::cerr << &*d->begin() << " " << &*d->end() << " "
<< &*d->end()-&*d->begin() << std::endl;
for (deque::iterator i = d->begin(); i != d->end(); ++i) {
std::cerr << i->x << ' ' << (int)i->y
<< " v=" << &*i
<< " cur=" << ((v*)&i)->a
<< " first=" << ((v*)&i)->b
<< " last=" << ((v*)&i)->c
<< " node=" << ((v*)&i)->d
<< std::endl;
if( i->y == 31 )
foo();
}
return 0;
}
void foo() { std::cerr << "faulty ++ is next" << std::endl;}
-
compiled on x86_64 with g++-3.4.4 -O2 -fno-strict-aliasing I get
$ ./runtest 32
0x6007c0 0x6009d0 33
0 0 v=0x6007c0 cur=0x6007c0 first=0x6007c0 last=0x6009c0 node=0x600788
0 1 v=0x6007d0 cur=0x6007d0 first=0x6007c0 last=0x6009c0 node=0x600788
0 2 v=0x6007e0 cur=0x6007e0 first=0x6007c0 last=0x6009c0 node=0x600788
[...]
0 30 v=0x6009a0 cur=0x6009a0 first=0x6007c0 last=0x6009c0 node=0x600788
0 31 v=0x6009b0 cur=0x6009b0 first=0x6007c0 last=0x6009c0 node=0x600788
faulty ++ is next
0 0 v=0x6009c0 cur=0x6009d0 first=0x6009d0 last=0x600bd0 node=0x600790
0 0 v=0x6009e0 cur=0x6009e0 first=0x6009d0 last=0x600bd0 node=0x600790
[...]
0 0 v=0x600bc0 cur=0x600bc0 first=0x6009d0 last=0x600bd0 node=0x600790
0 Segmentation fault
Looks like operator++ somehow jumps over d->end() and continues counting.
Without -fno-strict-aliasing everything seems just fine:
$ ./runtest 32
0x6007c0 0x6009d0 33
0 0 v=0x6007c0 cur=0x6007c0 first=0x6007c0 last=0x6009c0 node=0x600788
0 1 v=0x6007d0 cur=0x6007d0 first=0x6007c0 last=0x6009c0 node=0x600788
[...]
0 30 v=0x6009a0 cur=0x6009a0 first=0x6007c0 last=0x6009c0 node=0x600788
0 31 v=0x6009b0 cur=0x6009b0 first=0x6007c0 last=0x6009c0 node=0x600788
faulty ++ is next
Seems to me like _M_cur = _M_first is forgotten (or evaluated too late?) in
std::deque::operator++()
stl_deque.h:140
_Self&
operator++()
{
++_M_cur;
if (_M_cur == _M_last)
{
_M_set_node(_M_node + 1);
_M_cur = _M_first;
}
return *this;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21939
[Bug libstdc++/21955] std::stringbuf vs. in_avail
--- Additional Comments From pcarlini at suse dot de 2005-06-07 21:54 --- Hi Benjamin. I see: basically, we forgot to implement the stringbug::showmanyc virtual. Strictly speaking the current behavior is correct wrt the standard but indeed providing the natural one (as you are doing) improves consistency and QoI. If I read the patch correctly, besides testsuite and clean-ups, you basically implemented the expected showmanyc and that's definitely a nice idea! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21955
[Bug middle-end/21850] misscompiling comparision from vector to integer
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-07 21:45 --- Subject: Bug 21850 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-07 21:45:08 Modified files: gcc: ChangeLog tree.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20050607-1.c Log message: PR middle-end/21850 * tree.c (get_unwidened): Stop at NOP_EXPR/CONVERT_EXPR that convert from vector types. * gcc.c-torture/execute/20050607-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9074&r2=2.9075 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gcc&r1=1.486&r2=1.487 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5608&r2=1.5609 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050607-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21850
[Bug libstdc++/21955] std::stringbuf vs. in_avail
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-07 21:36 --- Yo P, can you comment on this at some point? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21955
[Bug libstdc++/21955] std::stringbuf vs. in_avail
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21955
[Bug libstdc++/21955] std::stringbuf vs. in_avail
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-07 21:28 --- Created an attachment (id=9045) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9045&action=view) patch Patch, testsuite reorg and additions -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21955
[Bug libstdc++/21955] New: std::stringbuf vs. in_avail
Basically, in_avail for stringbufs is missing key bits.
#include
#include
#include
double
test_stringstream()
{
double result;
char* source = "1918";
std::stringstream s;
s << source;
std::string tmp = s.str();
std::streambuf* sb = s.rdbuf();
int i = sb->in_avail();
if (i)
{
s >> result;
std::cerr << "conversion result = " << result << std::endl;
}
else
{
throw std::runtime_error("conversion failed");
}
return result;
}
int main ()
{
test_stringstream();
return 0;
}
I believe this to be a bug, and quite unintentional.
However, it's pretty easily fixed.
This is a tracker from RH bugzilla 159408
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159408
--
Summary: std::stringbuf vs. in_avail
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
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=21955
[Bug libfortran/21926] [4.0 only] matmul does not deal with non-packed result
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-07 20:53 --- Fixed in 4.1, waiting for 4.0 to reopen. -- What|Removed |Added Summary|matmul does not deal with |[4.0 only] matmul does not |non-packed result |deal with non-packed result Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21926
[Bug libfortran/21926] matmul does not deal with non-packed result
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-07 20:46 --- Subject: Bug 21926 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-07 20:46:17 Modified files: libgfortran: ChangeLog libgfortran/m4 : matmul.m4 libgfortran/generated: matmul_c4.c matmul_c8.c matmul_i4.c matmul_i8.c matmul_r4.c matmul_r8.c gcc/testsuite : ChangeLog gcc/testsuite/gfortran.fortran-torture/execute: intrinsic_matmul.f90 Log message: 2005-06-07 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/21926 * m4/matmul.m4: Correct zeroing of result for non-packed arrays with lowest stride is one. * generated/matmul_c4.c: Regenerated. * generated/matmul_c8.c: Regenerated. * generated/matmul_i4.c: Regenerated. * generated/matmul_i8.c: Regenerated. * generated/matmul_r4.c: Regenerated. * generated/matmul_r8.c: Regenerated. 2005-06-07 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/21926 * gfortran.fortran-torture/execute/intrinsic_matmul.f90: Test case where the return array has lowest stride one, but isn't packed. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.233&r2=1.234 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/matmul.m4.diff?cvsroot=gcc&r1=1.12&r2=1.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/matmul_c4.c.diff?cvsroot=gcc&r1=1.11&r2=1.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/matmul_c8.c.diff?cvsroot=gcc&r1=1.11&r2=1.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/matmul_i4.c.diff?cvsroot=gcc&r1=1.11&r2=1.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/matmul_i8.c.diff?cvsroot=gcc&r1=1.11&r2=1.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/matmul_r4.c.diff?cvsroot=gcc&r1=1.11&r2=1.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/matmul_r8.c.diff?cvsroot=gcc&r1=1.11&r2=1.12 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5607&r2=1.5608 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_matmul.f90.diff?cvsroot=gcc&r1=1.2&r2=1.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21926
[Bug testsuite/21954] gcc.dg/compat/struct-layout-1 fails to link on Tru64 UNIX V4.0F
-- What|Removed |Added Component|other |testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21954
[Bug other/21954] New: gcc.dg/compat/struct-layout-1 fails to link on Tru64 UNIX V4.0F
On Tru64 UNIX V4.0F, gcc.dg-struct-layout-1_generate fails to link since the platform lacks snprintf: Executing on host: gcc -g -O2 -o /vol/gcc/obj/gcc-4.1.0-20050525/4.0f-gcc/gcc/testsuite/gcc.dg-struct-layout-1_generate /vol/gnu/src/gcc/gcc-dist/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c /vol/gnu/src/gcc/gcc-dist/gcc/testsuite/gcc.dg/compat/generate-random.c /vol/gnu/src/gcc/gcc-dist/gcc/testsuite/gcc.dg/compat/generate-random_r.c (timeout = 300) snprintf collect2: ld returned 1 exit status WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator Therefore none of the generated tests are performed. Environment: System: OSF1 rimsky V4.0 1229 alpha Machine: alpha host: alpha-dec-osf4.0f build: alpha-dec-osf4.0f target: alpha-dec-osf4.0f configured with: /vol/gnu/src/gcc/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf4.0f --build alpha-dec-osf4.0f --target alpha-dec-osf4.0f --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 --with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3 --enable-languages=c,c++,f95,java,objc --disable-libmudflap How-To-Repeat: Bootstrap and test as described above. -- Summary: gcc.dg/compat/struct-layout-1 fails to link on Tru64 UNIX V4.0F Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: alpha-dec-osf4.0f GCC host triplet: alpha-dec-osf4.0f GCC target triplet: alpha-dec-osf4.0f http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21954
[Bug middle-end/21953] [4.1 Regression] Many tmpdir-gcc.dg-struct-layout-1 tests fail on Tru64 UNIX V5.1B
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-07 20:35 --- Most likely related to PR 21885. -- What|Removed |Added BugsThisDependsOn||21885 Component|target |middle-end Keywords||wrong-code Summary|Many tmpdir-gcc.dg-struct- |[4.1 Regression] Many |layout-1 tests fail on Tru64|tmpdir-gcc.dg-struct-layout- |UNIX V5.1B |1 tests fail on Tru64 UNIX ||V5.1B Target Milestone|--- |4.1.0 Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21953
[Bug middle-end/21885] [4.1 Regression] compat testsuite failures
-- What|Removed |Added OtherBugsDependingO||21953 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21885
[Bug target/21953] Many tmpdir-gcc.dg-struct-layout-1 tests fail on Tru64 UNIX V5.1B
-- What|Removed |Added Component|pending |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21953
[Bug pending/21953] New: Many tmpdir-gcc.dg-struct-layout-1 tests fail on Tru64 UNIX V5.1B
NOTE: Defaulting component because reported component no longer exists Many tmpdir-gcc.dg-struct-layout-1 tests fail on mainline on Tru64 UNIX V5.1B: FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t002 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t004 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t007 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t009 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t010 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t011 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t013 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t014 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t015 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t016 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t020 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t022 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t024 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t025 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o-c_compat_y_tst.o execute They all abort; still have to build a gdb that doesn't crash on the resulting binaries to further investigate. Environment: System: OSF1 bartok V5.1 2650 alpha Machine: alpha host: alpha-dec-osf5.1b build: alpha-dec-osf5.1b target: alpha-dec-osf5.1b configured with: /vol/gnu/src/gcc/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build alpha-dec-osf5.1b --target alpha-dec-osf5.1b --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 --with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3 --enable-languages=c,c++,f95,java,objc --disable-libmudflap How-To-Repeat: Bootstrap and run testsuite as above. -- Summary: Many tmpdir-gcc.dg-struct-layout-1 tests fail on Tru64 UNIX V5.1B Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: pending AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: alpha-dec-osf5.1b GCC host triplet: alpha-dec-osf5.1b GCC target triplet: alpha-dec-osf5.1b http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21953
[Bug ada/21952] New: Many attribute directive ignored warnings during Tru64 UNIX Ada bootstrap
During a mainline bootstrap with Ada included (and the patch from PR tree-optimization/21029 to avoid an infinite loop in stage3) on Tru64 UNIX, there occur many warnings like this: % stage1/xgcc -Bstage1/ -B/vol/gcc/share/alpha-dec-osf5.1b/bin/ -c -g -O2 -gnatpg -gnata -I- -I. -Iada -I/vol/gnu/src/gcc/gcc-dist/gcc/ada /vol/gnu/src/gcc/gcc-dist/gcc/ada/cstand.adb -o ada/cstand.o :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored [...] The warnings stem from from gcc/attribs.c (decl_attributes), e.g. (first call to decl_attributes): :0: warning: 'const' attribute directive ignored :0: warning: 'nothrow' attribute directive ignored 0x00012016fadc in builtin_function (name=0x14008b7d8 "__builtin_alpha_implver", type=0x3b6c0, function_code=26, class=BUILT_IN_MD, library_name=0x0, attrs=0x15bc0) at /vol/gnu/src/gcc/gcc-dist/gcc/ada/utils.c:1788 #0 decl_attributes (node=0x11fffbeb8, attributes=0x15bc0, flags=16) at /vol/gnu/src/gcc/gcc-dist/gcc/attribs.c:173 #1 0x00012016fadc in builtin_function (name=0x14008b7d8 "__builtin_alpha_implver", type=0x3b6c0, function_code=26, class=BUILT_IN_MD, library_name=0x0, attrs=0x15bc0) at /vol/gnu/src/gcc/gcc-dist/gcc/ada/utils.c:1788 #2 0x0001206e7264 in alpha_init_builtins () at /vol/gnu/src/gcc/gcc-dist/gcc/config/alpha/alpha.c:6271 #3 0x000120163eb8 in gnat_install_builtins () at /vol/gnu/src/gcc/gcc-dist/gcc/ada/utils.c:418 #4 0x000120163e6c in gnat_init_decl_processing () at /vol/gnu/src/gcc/gcc-dist/gcc/ada/utils.c:406 #5 0x00012015f5ac in gnat_init () at /vol/gnu/src/gcc/gcc-dist/gcc/ada/misc.c:400 #6 0x000120644200 in lang_dependent_init (name=0x11fffe120 "ada/sdefault.adb") at /vol/gnu/src/gcc/gcc-dist/gcc/toplev.c:2017 #7 0x00012064457c in do_compile () at /vol/gnu/src/gcc/gcc-dist/gcc/toplev.c:2122 #8 0x000120644640 in toplev_main (argc=10, argv=0x11fffc018) at /vol/gnu/src/gcc/gcc-dist/gcc/toplev.c:2155 #9 0x0001205e6a38 in main (argc=10, argv=0x11fffc018) at /vol/gnu/src/gcc/gcc-dist/gcc/main.c:35 They originate from this patch: 2005-03-08 Richard Henderson <[EMAIL PROTECTED]> * config/alpha/alpha.c (code_for_builtin): Replace special-case builtin codes with ctzdi2, clzdi2, popcountdi2. (struct alpha_builtin_def): Add is_const. (zero_arg_builtins, one_arg_builtins, two_arg_builtins): Init it. (alpha_v8qi_u, alpha_v8qi_s, alpha_v4hi_u, alpha_v4hi_s): New. (alpha_init_builtins): Init them. Set nothrow and const attributes on builtins. and occur even with a minimal Ada test program: procedure conftest is begin null; end conftest; stage1/gnat1 -I/vol/gnu/src/gcc/gcc-dist/gcc/ada conftest.adb Environment: System: OSF1 bartok V5.1 2650 alpha Machine: alpha host: alpha-dec-osf5.1b build: alpha-dec-osf5.1b target: alpha-dec-osf5.1b configured with: /vol/gnu/src/gcc/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build alpha-dec-osf5.1b --target alpha-dec-osf5.1b --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 --with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3 --enable-languages=c,c++,f95,java,objc,ada --disable-libmudflap How-To-Repeat: Bootstrap the compiler as above (which fails building gnattools due to PR ada/18434). -- Summary: Many attribute directive ignored warnings during Tru64 UNIX Ada bootstrap Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: alpha-dec-osf5.1b GCC host triplet: alpha-dec-osf5.1b GCC target triplet: alpha-dec-osf5.1b http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
[Bug middle-end/21728] [4.0/4.1 Regression] Nonlocal goto from an unused nested function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-07
20:11 ---
Reduced testcase:
int main (void)
{
__label__ l1;
void q(void)
{
goto l1;
}
l1:;
}
--
What|Removed |Added
Summary|[4.0/4.1 Regression]|[4.0/4.1 Regression]
|Nonlocal gotos between |Nonlocal goto from an unused
|nested functions cause |nested function
|undefined labels in |
|assembler output|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21728
[Bug fastjar/21826] fastjar does not look to see if mkdir takes one or two arguments
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-07 20:02 --- (In reply to comment #3) > Same thing happens when compiling libgcov (this is indeed a regression, since > we > can't build GCC anymore on i386-mingw32). That is PR 21597. -- What|Removed |Added OtherBugsDependingO||21597 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-07 20:02:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21826
[Bug tree-optimization/21861] [meta-bug] scalar evolution type conversion
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr 2005-06-07 20:02 --- fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21861
[Bug fastjar/21826] fastjar does not look to see if mkdir takes one or two arguments
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-07 20:01 --- Same thing happens when compiling libgcov (this is indeed a regression, since we can't build GCC anymore on i386-mingw32). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21826
[Bug tree-optimization/20742] [4.0 Regression] Hang in tree_ssa_iv_optimize_loop
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-07 19:54 --- Subject: Bug 20742 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-07 19:54:23 Added files: gcc/testsuite/gcc.c-torture/compile: 20050423-1.c Log message: * 20050423-1.c: Testcase for PR tree-optimization/20742. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/20050423-1.c.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20742
[Bug tree-optimization/18403] FAILs to vectorize testcases on ppc64-linux
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-07 19:51 --- Subject: Bug 18403 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-07 19:51:26 Modified files: gcc: ChangeLog Makefile.in tree-chrec.c tree-chrec.h tree-flow.h tree-scalar-evolution.c tree-ssa-loop-ivopts.c tree-ssa-loop-niter.c tree-vrp.c gcc/testsuite/gcc.dg/vect: vect-77.c vect-78.c Log message: Fixes PR 18403 and meta PR 21861. * Makefile.in (tree-chrec.o): Depend on CFGLOOP_H and TREE_FLOW_H. * tree-chrec.c: Include cfgloop.h and tree-flow.h. (evolution_function_is_invariant_rec_p, evolution_function_is_invariant_p): New. (chrec_convert): Use an extra parameter AT_STMT for refining the information that is passed down to convert_step. Integrate the code that was in count_ev_in_wider_type. * tree-chrec.h (count_ev_in_wider_type): Removed. (chrec_convert): Modify its declaration. (evolution_function_is_invariant_p): Declared. (evolution_function_is_affine_p): Use evolution_function_is_invariant_p. * tree-flow.h (can_count_iv_in_wider_type): Renamed convert_step. (scev_probably_wraps_p): Declared. * tree-scalar-evolution.c (count_ev_in_wider_type): Removed. (follow_ssa_edge_in_rhs, interpret_rhs_modify_expr): Use an extra parameter AT_STMT for refining the information that is passed down to convert_step. (follow_ssa_edge_inner_loop_phi, follow_ssa_edge, analyze_scalar_evolution_1): Initialize AT_STMT with the current analyzed statement. (instantiate_parameters_1): Don't know yet how to initialize AT_STMT. * tree-ssa-loop-ivopts.c (idx_find_step): Update the use of can_count_iv_in_wider_type to use convert_step. * tree-ssa-loop-niter.c (can_count_iv_in_wider_type_bound): Move code that is independent of the loop over the known iteration bounds to convert_step_widening, the rest is moved to proved_non_wrapping_p. (scev_probably_wraps_p): New. (can_count_iv_in_wider_type): Renamed convert_step. * tree-vrp.c (adjust_range_with_scev): Take an extra AT_STMT parameter. Use scev_probably_wraps_p for computing init_is_max. (vrp_visit_assignment): Pass the current analyzed statement to adjust_range_with_scev. (execute_vrp): Call estimate_numbers_of_iterations for refining the information provided by scev analyzer. testsuite: * testsuite/gcc.dg/vect/vect-77.c: Remove xfail from lp64. * testsuite/gcc.dg/vect/vect-78.c: Same. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9071&r2=2.9072 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&r1=1.1500&r2=1.1501 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-chrec.c.diff?cvsroot=gcc&r1=2.19&r2=2.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-chrec.h.diff?cvsroot=gcc&r1=2.8&r2=2.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow.h.diff?cvsroot=gcc&r1=2.118&r2=2.119 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-scalar-evolution.c.diff?cvsroot=gcc&r1=2.27&r2=2.28 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcc&r1=2.76&r2=2.77 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-niter.c.diff?cvsroot=gcc&r1=2.28&r2=2.29 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gcc&r1=2.23&r2=2.24 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-77.c.diff?cvsroot=gcc&r1=1.10&r2=1.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-78.c.diff?cvsroot=gcc&r1=1.11&r2=1.12 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18403
[Bug tree-optimization/21861] [meta-bug] scalar evolution type conversion
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-07 19:51 --- Subject: Bug 21861 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-07 19:51:26 Modified files: gcc: ChangeLog Makefile.in tree-chrec.c tree-chrec.h tree-flow.h tree-scalar-evolution.c tree-ssa-loop-ivopts.c tree-ssa-loop-niter.c tree-vrp.c gcc/testsuite/gcc.dg/vect: vect-77.c vect-78.c Log message: Fixes PR 18403 and meta PR 21861. * Makefile.in (tree-chrec.o): Depend on CFGLOOP_H and TREE_FLOW_H. * tree-chrec.c: Include cfgloop.h and tree-flow.h. (evolution_function_is_invariant_rec_p, evolution_function_is_invariant_p): New. (chrec_convert): Use an extra parameter AT_STMT for refining the information that is passed down to convert_step. Integrate the code that was in count_ev_in_wider_type. * tree-chrec.h (count_ev_in_wider_type): Removed. (chrec_convert): Modify its declaration. (evolution_function_is_invariant_p): Declared. (evolution_function_is_affine_p): Use evolution_function_is_invariant_p. * tree-flow.h (can_count_iv_in_wider_type): Renamed convert_step. (scev_probably_wraps_p): Declared. * tree-scalar-evolution.c (count_ev_in_wider_type): Removed. (follow_ssa_edge_in_rhs, interpret_rhs_modify_expr): Use an extra parameter AT_STMT for refining the information that is passed down to convert_step. (follow_ssa_edge_inner_loop_phi, follow_ssa_edge, analyze_scalar_evolution_1): Initialize AT_STMT with the current analyzed statement. (instantiate_parameters_1): Don't know yet how to initialize AT_STMT. * tree-ssa-loop-ivopts.c (idx_find_step): Update the use of can_count_iv_in_wider_type to use convert_step. * tree-ssa-loop-niter.c (can_count_iv_in_wider_type_bound): Move code that is independent of the loop over the known iteration bounds to convert_step_widening, the rest is moved to proved_non_wrapping_p. (scev_probably_wraps_p): New. (can_count_iv_in_wider_type): Renamed convert_step. * tree-vrp.c (adjust_range_with_scev): Take an extra AT_STMT parameter. Use scev_probably_wraps_p for computing init_is_max. (vrp_visit_assignment): Pass the current analyzed statement to adjust_range_with_scev. (execute_vrp): Call estimate_numbers_of_iterations for refining the information provided by scev analyzer. testsuite: * testsuite/gcc.dg/vect/vect-77.c: Remove xfail from lp64. * testsuite/gcc.dg/vect/vect-78.c: Same. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9071&r2=2.9072 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&r1=1.1500&r2=1.1501 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-chrec.c.diff?cvsroot=gcc&r1=2.19&r2=2.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-chrec.h.diff?cvsroot=gcc&r1=2.8&r2=2.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-flow.h.diff?cvsroot=gcc&r1=2.118&r2=2.119 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-scalar-evolution.c.diff?cvsroot=gcc&r1=2.27&r2=2.28 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcc&r1=2.76&r2=2.77 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-niter.c.diff?cvsroot=gcc&r1=2.28&r2=2.29 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gcc&r1=2.23&r2=2.24 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-77.c.diff?cvsroot=gcc&r1=1.10&r2=1.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/vect-78.c.diff?cvsroot=gcc&r1=1.11&r2=1.12 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21861
[Bug tree-optimization/21831] [4.1 Regression] gcc.dg/vect/vect-97.c fails
--- Additional Comments From dorit at il dot ibm dot com 2005-06-07 19:49 --- > When were you seeing it on those platforms? My monitoring has never shown > this as an i686-pc-linux-gnu failure, but it still fails on ia64-hpux, > both -milp32 and -mlp64, as of today's mainline. you're right, I might have never seen this failure on these platforms. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21831
[Bug middle-end/21528] [4.0 Regression] Boost shared_ptr_test.cpp fails with -O3
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-06-07
19:48 ---
This seems to be an RTL bug in 4.0. None of the tree optimizers seem to be
doing anything wrong with this code. However, applying this patch to the test
case:
--- sp_test.ii 2005-06-06 12:02:57.0 -0400
+++ pr21528.cc 2005-06-07 15:44:49.297961371 -0400
@@ -3152,7 +3152,9 @@ inline int atomic_exchange_and_add( int
inline void atomic_increment( int * pw )
{
-
+#if defined HACK
+ *pw = *pw + 1;
+#else
__asm__
(
"lock\n\t"
@@ -3161,6 +3163,7 @@ inline void atomic_increment( int * pw )
"m"( *pw ):
"cc"
);
+#endif
}
inline int atomic_conditional_increment( int * pw )
works around the problem. The bug seems to be introduced by the RTL optimizers.
The second call to atomic_increment is being removed in .CE1. Here's some IRC
analysis:
dnovillo: pong
rth: been looking at 21528 (4.0 regression) for a while now and
afaict none of the tree optimizers are doing anything wrong. i think it may be
an inline asm thing:
inline void atomic_increment( int * pw )
{
#if defined HACK
*pw = *pw + 1;
#else
__asm__
(
"lock\n\t"
"incl %0":
"=m"( *pw ):
"m"( *pw ):
"cc"
);
#endif
}
if i compile with -DHACK, it works. Otherwise, it fails.
(at -O3)
hmm is there a V_MAY_DEF for the inline-asm?
dnovillo: inline asm looks ok. you've not logged anything to the pr that
looks useful. or wrong pr number?
rth: not yet. first i wanted to know if the inline looked fine.
the tree dumps are identical modulo the __asm__ bits, the .s files
only differ in:
--- 00bad/pr21528.s 2005-06-07 15:24:37.651935299 -0400
+++ 00good/pr21528.s2005-06-07 15:25:11.150401900 -0400
@@ -384,10 +384,7 @@ main:
movl-16(%ebp), %esi
testl %esi, %esi
je .L57
-#APP
- lock
- incl 4(%esi)
-#NO_APP
+ addl$2, 4(%esi)
testl %esi, %esi
je .L57
cmpl$3, 4(%esi)
which is odd.
that is odd.
it's as if one __asm__ call is being lost
well, is it?
not in the tree optimizers, for sure. gimme a minute.
It's like thousands of inline lock routines shouted out all at once
and then vanished
actually, no it isn't.
i don't believe in anthromorphic lock routines.
so where did the lock go
oh
:)
just wait till we have biological computers
there's an extra couple of letters in that word. i'll let you fix them up
on your end.
in .expand, there is only one lock incl
:q
well, the trees look fine at .final_cleanup
pw = &pv$pn$pi_->use_count_;|pw =
&pv$pn$pi_->use_count_;
# TMT.247_999 = V_MAY_DEF __asm__("lock\n\tincl %0":"=m" *pw:"|*pw = *pw + 1;
[ ... ] |
pw = &pv$pn$pi_->use_count_;|pw =
&pv$pn$pi_->use_count_;
# TMT.247_998 = V_MAY_DEF __asm__("lock\n\tincl %0":"=m" *pw:"|*pw = *pw + 1;
never mind looking at the wrong dump
what's the rtl dump switch?
-da or -fdump-rtl-all
-fdump-tree-expand.
It disappears in pr21528.cc.11.ce1
(the second __asm__ ("lock"), that is)
hmm. cse bug invalidating memories?
dump state into the pr and i'll look at it
will do. thanks.
--
What|Removed |Added
AssignedTo|dnovillo at gcc dot gnu dot |rth at gcc dot gnu dot org
|org |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21528
[Bug c++/21951] [gcc-4.0 regression, rejects-valid] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
--- Additional Comments From veksler at il dot ibm dot com 2005-06-07 19:46 --- (In reply to comment #3) > Paolo I copied the quote fully when I really should not have. RTH did not know we could not fix the > if(0) part in libstdc++ at the time he wrote that comment, if you read the next comment in that bug I > explain why it cannot be fixed in libstdc++ (comment #3 in PR 19699): > (In reply to comment #2) > > You may retartget this pr to fixing the silliness in libstdc++, if you want. > Actually it is only silliness as try/catch is changed to be "if (true)"/"if (false)" if we don't have exceptions. > There is nothing can be done to the libstdc++ headers to fix this. I disagree. libstdc++ can do exactly what everybody else does in such cases: add a dummy (unreachable) "return __result" at the end, after both try and catch blocks. This will be a hack, no doubt, a pragmatic one. I don't think that emitting false positive diagnostic that the user does not control is a good thing. I have been working in a verification (research) department for 10 years, and I can assure you that false positives, which can't be turned off, are worse than no diagnostic at all. Such diagnostics *will* turn customers/users away from your tool, or at best "just" ignore diagnostics. I have used a (bought) tool that gave a false positive every 500 lines of code. For 500 KLOC it would give 1K false positive. Now, try to find out a single true bug out of the noise of 1000 false positives. I can tell you that the tool was dropped very fast. We write tools used for verification and testing. Our customers are more likely to be willing to live with uncovered events, than to get false positives. Think of millions of tests/events that cause even 0.1% of false positive. These may overshadow hundreds of real bugs. Same with gcc, if something as central as vector.reserve() give false positive diagnostics then the sheer volume of warnings will render either the warning or reserve() unusable. I suggest to reopen PR19699 against libstdc++ (or maybe open a new one) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug c++/19894] pointer-to-void member not rejected in template
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-07 19:39 --- No, it's really a bug. In 3.9.2 [basic.compound] we have: Compound types can be constructed in the following ways: [...] - pointers to void or objects or functions (...) of a given type, [...] - pointers to non-static class members, which identify members of a given type within objects of a given class. This also shows that no pointers to members of type void are allowed: a) There is no such thing as a void data member in a class. b) For regular pointers "void" is added explicitly, but not for pointers to members. BTW, the compiler rejects them in the non-template case. This is only an omission in the template case. I'm testing a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19894
[Bug libfortran/20930] [4.0 Regression] gfortran.dg/backspace.f execution test
--- Additional Comments From dje at gcc dot gnu dot org 2005-06-07 19:15 --- gfortran patches are not being backported as originally promised. -- What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20930
[Bug c++/21783] [DR 409] Typename for required for qualified name?
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-07 19:07 --- > There is a DR and surely another bug report about this. It's uncertain > whether > typename is needed to disambiguate a qualified name where the scope is the > injected class name (which always refers to the current instantiation). You're right Giovanni, it's DR 409. The proposed solution is to not require the "typename". But then we'd also have a bug, because GCC had to accept the declaration A::B b; So with either outcome of the DR, we'll have to change the compiler. Let's suspend it until the DR is solved. -- What|Removed |Added Status|NEW |SUSPENDED Summary|No typename required when |[DR 409] Typename for |type use in a function |required for qualified name? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21783
[Bug ada/21937] [4.0 Regression] Member record alignment triggers an ICE
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-06-07 18:56 --- > Well, you may have noticed I'm already aware of this -- otherwise I wouldn't > have filed the report in the first place. But the problem is the i386 is > probably the architecture most code is primarily tested with and unfortunately > it has quite forgiving restrictions about alignment. The 4.0.x Ada compiler has been regularly tested on PowerPC and SPARC too (apart from being interested in Ada, I'm also a SPARC maintainer) so it shouldn't be that broken on non-x86 platforms. However it is true that RISC platforms are more demanding than x86, at least as far as Ada is concerned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21937
[Bug c++/21783] No typename required when type use in a function
--- Additional Comments From giovannibajo at libero dot it 2005-06-07 18:45 --- There is a DR and surely another bug report about this. It's uncertain whether typename is needed to disambiguate a qualified name where the scope is the injected class name (which always refers to the current instantiation). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21783
[Bug c++/21951] [gcc-4.0 regression, rejects-valid] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-07 18:16 --- (In reply to comment #2) > > You may retartget this pr to fixing the silliness in libstdc++, if you want. Paolo I copied the quote fully when I really should not have. RTH did not know we could not fix the if(0) part in libstdc++ at the time he wrote that comment, if you read the next comment in that bug I explain why it cannot be fixed in libstdc++ (comment #3 in PR 19699): (In reply to comment #2) > You may retartget this pr to fixing the silliness in libstdc++, if you want. Actually it is only silliness as try/catch is changed to be "if (true)"/"if (false)" if we don't have exceptions. There is nothing can be done to the libstdc++ headers to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug ada/21937] [4.0 Regression] Member record alignment triggers an ICE
--- Additional Comments From macro at linux-mips dot org 2005-06-07 18:16 --- > > Of course it changes the ABI -- if any member of a record (which is an > > equivalent to a C structure) gets its alignment increased, then the > > alignment > > of the containing record (structure) gets adjusted appropriately. > > Sure, but since all records of this type will be laid out the same way, where > is > the problem? This only happens for packed records or records with After a short consideration I agree -- it would only be a problem if the case was reversed, i.e. standalone records got their alignment bumped while member oned did not. > representation clauses, both not bound to any ABI rules as far as Ada is concerned. Well, there may be no written standard for this case, but there is always an ABI, even if limited to GCC. > > If I understand code correctly compute_record_mode() should still be able to > > use one of the integer modes for platforms that don't care about alignment. > > x86 is not (yet) the only platform out there. :-) Well, you may have noticed I'm already aware of this -- otherwise I wouldn't have filed the report in the first place. But the problem is the i386 is probably the architecture most code is primarily tested with and unfortunately it has quite forgiving restrictions about alignment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21937
[Bug c++/21951] [gcc-4.0 regression, rejects-valid] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
--- Additional Comments From pcarlini at suse dot de 2005-06-07 18:12 --- > You may retartget this pr to fixing the silliness in libstdc++, if you want. And the "silliness" would be? Personally, I'm finding quite a bit of silliness in this remark, to tell you the truth and indeed, mainline is ok, probably the current compiler judges that "silliness" not so silly, after all. When -fno-exceptions, the catch becomes simply an 'if (false)' and I don't see why the implementors of v3 have necessarily to care about the branch not returning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug middle-end/19699] [4.0/4.1 Regression] warning about not returning from end of a non-void function because of dead code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-07 18:00 --- *** Bug 21951 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||dank at kegel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19699
[Bug c++/21951] [gcc-4.0 regression, rejects-valid] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-07 18:00 --- And I already filed this way back, see PR 19699 which I am closing this bug as a dup. See comment #2 in that PR from RTH: There is zero chance that this will be fixed for 4.0. That's exactly why Ian implemented the minimalistic check that he did in solving PR19583 and related. You may retartget this pr to fixing the silliness in libstdc++, if you want. *** This bug has been marked as a duplicate of 19699 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug c++/21951] New: [gcc-4.0 regression, rejects-valid] std::vector.reserve() unusable with -Werror -Wall -O -fno-exceptions
Compiling the following code:
#include
std::vector *factory()
{
std::vector *p = new std::vector;
p->reserve(10);
return p;
}
with -Wall -O -fno-exceptions yields the following error in gcc-4.0.0
and gcc-4.0-20050602:
.../include/c++/4.0.0/bits/vector.tcc: In member function 'void std::vector<_Tp,
_Alloc>::reserve(size_t) [with _Tp = int, _Alloc = std::allocator]':
.../include/c++/4.0.0/bits/vector.tcc:78: warning: control may reach end of
non-void function 'typename _Alloc::pointer std::vector<_Tp,
_Alloc>::_M_allocate_and_copy(size_t, _ForwardIterator, _ForwardIterator) [with
_ForwardIterator = int*, _Tp = int, _Alloc = std::allocator]' being inlined
The warning comes from a catch/rethrow block deep in the bowels of stl
which (because of -fno-exceptions) evaluates to if(false).
This is a false positive warning, which would be fine except
for shops whose policy is to always compile with -Werror -Wall;
there, the warning is fatal. And because this problem is not
confined to just one user source file, it's hard to work around.
This problem does not occur in gcc-3.4.3 nor in recent gcc-4.1 snapshots.
cf. discussion here: http://gcc.gnu.org/ml/libstdc++/2005-06/msg00073.html
--
Summary: [gcc-4.0 regression, rejects-valid]
std::vector.reserve() unusable with -Werror -Wall -O -
fno-exceptions
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21951
[Bug testsuite/21094] libmudflap C++ tests run even when C++ not configured
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-07 17:11 --- *** Bug 21947 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||giovannibajo at libero dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21094
[Bug testsuite/21947] libmudflap C++ testsuite executed even if c++ is not enabled
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-07 17:11 --- Yes it is, I knew that there was one somewhere but I forgot where. *** This bug has been marked as a duplicate of 21094 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21947
[Bug tree-optimization/21831] [4.1 Regression] gcc.dg/vect/vect-97.c fails
--- Additional Comments From joseph at codesourcery dot com 2005-06-07 17:10 --- Subject: Re: [4.1 Regression] gcc.dg/vect/vect-97.c fails On Tue, 7 Jun 2005, dorit at il dot ibm dot com wrote: > > --- Additional Comments From dorit at il dot ibm dot com 2005-06-07 > 07:42 --- > > I tried vect-97.c on power-pc and couldn't reproduce the problem. > > I don't know if this means that the problem goes away with recent > > patches or that it only occurs when vectorizing on ia64. I don't > > have the ability to build and test on ia64. > > I don't see this failure anymore on i686-pc-linux-gnu and > powerpc-apple-darwin. When were you seeing it on those platforms? My monitoring has never shown this as an i686-pc-linux-gnu failure, but it still fails on ia64-hpux, both -milp32 and -mlp64, as of today's mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21831
[Bug c++/21783] No typename required when type use in a function
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-07 17:07 --- Confirmed. It's in the standard from 1998: [14.6]/6 -- What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||monitored Last reconfirmed|-00-00 00:00:00 |2005-06-07 17:07:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21783
[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-07 16:55 --- Should be fixed now. Thanks all for testing/reviewing so quickly. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21847
[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-07 16:54 --- Subject: Bug 21847 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-07 16:54:16 Modified files: gcc: ChangeLog tree-ssa-dce.c Log message: PR tree-optimization/21847 * tree-ssa-dce.c (mark_stmt_if_obviously_necessary): With -fnon-call-exceptions, also mark statements inherently necessary if they may throw. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9069&r2=2.9070 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-dce.c.diff?cvsroot=gcc&r1=2.44&r2=2.45 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21847
[Bug testsuite/21947] libmudflap C++ testsuite executed even if c++ is not enabled
--- Additional Comments From joseph at codesourcery dot com 2005-06-07 16:50 --- Subject: Re: New: libmudflap C++ testsuite executed even if c++ is not enabled On Tue, 7 Jun 2005, giovannibajo at libero dot it wrote: > I don't think libmudflap.c++ should be run if C++ was not built. Surely this is just bug 21094? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21947
[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-07 16:49 --- Subject: Bug 21847 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-06-07 16:48:53 Modified files: gcc: ChangeLog tree-ssa-dce.c Log message: PR tree-optimization/21847 * tree-ssa-dce.c (mark_stmt_if_obviously_necessary): With -fnon-call-exceptions, also mark statements inherently necessary if they may throw. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.281&r2=2.7592.2.282 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-dce.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.32.4.1&r2=2.32.4.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21847
[Bug libfortran/21950] All gfortran execution tests fail on Tru64 UNIX V4.0F: scalbn unresolved
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-07 16:23 --- Another C99 math function missing. -- What|Removed |Added BugsThisDependsOn||15234 OtherBugsDependingO||16991 nThis|| Component|fortran |libfortran Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21950
[Bug fortran/21950] New: All gfortran execution tests fail on Tru64 UNIX V4.0F: scalbn unresolved
Even with the patch to fix PR libfortran/15234 http://gcc.gnu.org/ml/fortran/2005-06/msg00118.html (and already mentioned there), all gfortran execution tests fail on alpha-dec-osf4.0f like this: % LD_LIBRARY_PATH=../../alpha-dec-osf4.0f/libgfortran/.libs:.. ./PR19754_2.exe 4552:./PR19754_2.exe: /sbin/loader: Error: Unresolved symbol in ../../alpha-dec-osf4.0f/libgfortran/.libs/libgfortran.so.0: scalbn 4552:./PR19754_2.exe: /sbin/loader: Fatal Error: this executable has unresolvable symbols The platform has no definition of scalbn whatsoever. Environment: System: OSF1 rimsky V4.0 1229 alpha Machine: alpha host: alpha-dec-osf4.0f build: alpha-dec-osf4.0f target: alpha-dec-osf4.0f configured with: /vol/gnu/src/gcc/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf4.0f --build alpha-dec-osf4.0f --target alpha-dec-osf4.0f --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 --with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3 --enable-languages=c,c++,f95,java,objc --disable-libmudflap How-To-Repeat: Bootstrap and test mainline (or the 4.0 branch) on alpha-dec-osf4.0f with the patch above applied. --- Additional Comments From ro at techfak dot uni-bielefeld dot de 2005-06-07 16:21 --- Fix: Provide a scalbn replacement. E.g. there is one in libjava (java/lang/s_scalbn.c). -- Summary: All gfortran execution tests fail on Tru64 UNIX V4.0F: scalbn unresolved Product: gcc Version: unknown Status: UNCONFIRMED Severity: critical Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: alpha-dec-osf4.0f GCC host triplet: alpha-dec-osf4.0f GCC target triplet: alpha-dec-osf4.0f http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21950
[Bug libgcj/21949] java.rmi.server.RMIClassLoader.getClassLoader() is private, should be public
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-07 15:51 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-07 15:51:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21949
[Bug libgcj/21949] java.rmi.server.RMIClassLoader.getClassLoader() is private, should be public
--- Additional Comments From gbenson at redhat dot com 2005-06-07 15:45 --- Created an attachment (id=9044) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9044&action=view) Fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21949
[Bug libgcj/21949] New: java.rmi.server.RMIClassLoader.getClassLoader() is private, should be public
The getClassLoader method of java.rmi.server.RMIClassLoader is private, but it should be public according to the spec. The attached patch fixes. http://java.sun.com/j2se/1.4.2/docs/api/java/rmi/server/RMIClassLoader.html#getClassLoader(java.lang.String) -- Summary: java.rmi.server.RMIClassLoader.getClassLoader() is private, should be public Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gbenson at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21949
[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code
--- Additional Comments From mark at codesourcery dot com 2005-06-07 15:45 --- Subject: Re: [4.0/4.1 Regression] misscompiling of the following java code steven at gcc dot gnu dot org wrote: > --- Additional Comments From steven at gcc dot gnu dot org 2005-06-07 > 07:48 --- > Re. comments #13 and #13, I _already_ said it should be "true" in comment #8 > ;-) > > I'll commit the patch tonight. Mark, is this approval also for the 4.0 > branch? Since I haven't built RC1 yet, yes, it is. Please commit ASAP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21847
[Bug middle-end/21897] [4.1 Regression] Segementation fault in fold_ternary
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-07 15:27 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21897
[Bug debug/21946] [4.0 Regression] Invalid DWARF2 debug info emitted
-- What|Removed |Added Keywords||wrong-debug Known to work||4.1.0 Last reconfirmed|2005-06-07 08:41:52 |2005-06-07 15:20:16 date|| Summary|Invalid DWARF2 debug info |[4.0 Regression] Invalid |emitted |DWARF2 debug info emitted Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21946
[Bug c++/16617] Fail to do access checking correctly for non-dependent qualified-id
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-06-07 14:58 --- Patch withdrawn due to overlooking default function argument and default template argument. No nice solution is found yet. -- What|Removed |Added AssignedTo|lerdsuwa at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Keywords|patch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16617
[Bug c++/18681] [3.4/4.0/4.1 Regression] template friend declaration not recognized
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-06-07 14:57 --- Patch withdrawn due to overlooking default function argument and default template argument. No nice solution is found yet. -- What|Removed |Added AssignedTo|lerdsuwa at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Keywords|patch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18681
[Bug c++/21312] [3.4/4.0/4.1 Regression] Access violation diagnostic given twice
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-06-07 14:57 --- Patch withdrawn due to overlooking default function argument and default template argument. No nice solution is found yet. -- What|Removed |Added AssignedTo|lerdsuwa at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Keywords|patch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21312
[Bug c/21948] [diagnostic] enable errors on `cast from/to pointer to/from integer of different size`
-- What|Removed |Added Component|other |c Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21948
[Bug other/21948] New: [diagnostic] enable errors on `cast from/to pointer to/from integer of different size`
It would be nice to see a -Werror-cast-size option on 64-bits archs. -Werror-cast-size could help develop portable (32/64-bits) software. -- Summary: [diagnostic] enable errors on `cast from/to pointer to/from integer of different size` Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21948
[Bug ada/21937] Member record alignment triggering an ICE
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-06-07 12:26 --- > It's hard to argue for me as Ada is not a language I'm familiar with, but > the problematic assignment is: > > return Ch.Attr; > > in Get_Character_Attribute() and both Ch.Attr and the return value of the > function are declared as Character_Attribute_Set, so I guess they are both > of the same type, aren't they. No, the types are not the same in the IL, that's why they can get different machine modes. > Of course it changes the ABI -- if any member of a record (which is an > equivalent to a C structure) gets its alignment increased, then the alignment > of the containing record (structure) gets adjusted appropriately. Sure, but since all records of this type will be laid out the same way, where is the problem? This only happens for packed records or records with representation clauses, both not bound to any ABI rules as far as Ada is concerned. > If I understand code correctly compute_record_mode() should still be able to > use one of the integer modes for platforms that don't care about alignment. x86 is not (yet) the only platform out there. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21937
[Bug middle-end/21850] misscompiling comparision from vector to integer
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-07 12:20:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21850
[Bug ada/21937] Member record alignment triggering an ICE
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-06-07 12:16 --- This worked in 3.4.x because we added a conversion operator: tree_transform : expand_return (build_binary_op (MODIFY_EXPR, NULL_TREE, DECL_RESULT (current_function_decl), gnu_ret_val)); In 4.x we directly build a MODIFY_EXPR: gnat_to_gnu : if (gnu_ret_val) gnu_result = build2 (MODIFY_EXPR, TREE_TYPE (gnu_ret_val), gnu_lhs, gnu_ret_val); Reinstating build_binary_op yields an ICE in the gimplifier instead, so either build_binary_op or the gimplifier would probably need to be tweaked a bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21937
[Bug ada/21937] Member record alignment triggering an ICE
--- Additional Comments From macro at linux-mips dot org 2005-06-07 12:14 --- > That's not quite true, the type is not the same. It's hard to argue for me as Ada is not a language I'm familiar with, but the problematic assignment is: return Ch.Attr; in Get_Character_Attribute() and both Ch.Attr and the return value of the function are declared as Character_Attribute_Set, so I guess they are both of the same type, aren't they. > How does that change the ABI for the containing record type? The type is laid > out only once. As for members, this is only done for non-aliased members so > ABI > considerations are irrelevant. Of course it changes the ABI -- if any member of a record (which is an equivalent to a C structure) gets its alignment increased, then the alignment of the containing record (structure) gets adjusted appropriately. Otherwise the member's record alignment requirement couldn't possibly be satisfied at the link time. And of course the alignment does matter for platforms that care about alignment as different machine code may be needed to access data. > > 2005-06-07 Maciej W. Rozycki <[EMAIL PROTECTED]> > > > > * ada/decl.c (make_packable_type): Use the same alignment for the > > new > > type. > > That would defeat the purpose of make_packable_type. If I understand code correctly compute_record_mode() should still be able to use one of the integer modes for platforms that don't care about alignment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21937
[Bug tree-optimization/21562] [4.0 Regression] Quiet bad codegen (unrolling + tail call interaction)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-07 11:42 --- (In reply to comment #8) > So is this fixed now? On the mainline yes but not on the 4.0 branch. -- What|Removed |Added Status|WAITING |NEW Last reconfirmed|2005-05-14 00:24:40 |2005-06-07 11:42:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21562
[Bug ada/21937] Member record alignment triggering an ICE
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-06-07 11:31 --- Investigating. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-06-07 11:30:35 |2005-06-07 11:31:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21937
[Bug ada/21937] Member record alignment triggering an ICE
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-06-07 11:30 --- > This problem happens for platforms that set STRICT_ALIGNMENT. For them it is > possible for a given record type to be expressed using an integer mode if used > as a member record, and the BLK mode if used standalone. As a result an > assignment where lhs is BLKmode and rhs is *Imode may be generated and this > triggers an ICE. That's not quite true, the type is not the same. > I've been able to track the problem down to the alignment of member records > being increased implicitly in an attempt to fit them into an integer mode. > I believe it is incorrect as it changes the alignment of the containing > record as well and therefore it changes the ABI. How does that change the ABI for the containing record type? The type is laid out only once. As for members, this is only done for non-aliased members so ABI considerations are irrelevant. > 2005-06-07 Maciej W. Rozycki <[EMAIL PROTECTED]> > > * ada/decl.c (make_packable_type): Use the same alignment for the new > type. That would defeat the purpose of make_packable_type. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-07 11:30:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21937
[Bug ada/21937] Member record alignment triggering an ICE
--- Additional Comments From macro at linux-mips dot org 2005-06-07 10:28 --- Here are details missing from the original report (sorry about that). This is output from the compiler when the ICE happens: 4.0.0 (alpha-unknown-linux-gnu) GCC error: in simplify_subreg, at simplify-rtx.c:3726 Error detected at terminal_interface-curses.adb:2559:1 [...] raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:387 This is a ChangeLog entry for the patch: 2005-06-07 Maciej W. Rozycki <[EMAIL PROTECTED]> * ada/decl.c (make_packable_type): Use the same alignment for the new type. Finally, as I have a native compiler for an affected platform, specifically mipsel-linux-gnu, I have run the Ada testsuite both without and with the patch applied and the change hasn't introduced any regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21937
[Bug fortran/21912] Wrong implied do-loop
--- Additional Comments From tobi at gcc dot gnu dot org 2005-06-07 10:18 --- I thought I had already ... -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21912
[Bug debug/21946] Invalid DWARF2 debug info emitted
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-07 10:17 --- Subject: Bug 21946 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-07 10:17:36 Modified files: gcc: ChangeLog dwarf2out.c var-tracking.c Makefile.in Log message: PR debug/21946 * dwarf2out.c (add_loc_descr_op_piece): New function. (multiple_reg_loc_descriptor, concat_loc_descriptor, loc_descriptor): Use it. * var-tracking.c: Include regs.h and expr.h. (emit_note_insn_var_location): Skip over pieces where offset is smaller than previous offset plus previous piece mode size. Optimize adjacent hard registers or memory locations. * Makefile.in (var-tracking.o): Depend on $(REGS_H) and $(EXPR_H). Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9065&r2=2.9066 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gcc&r1=1.597&r2=1.598 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/var-tracking.c.diff?cvsroot=gcc&r1=2.28&r2=2.29 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&r1=1.1498&r2=1.1499 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21946
[Bug tree-optimization/21933] [4.1 regression] ICE with -ftree-vectorize
--- Additional Comments From dorit at il dot ibm dot com 2005-06-07 10:13 --- I also see this on powerpc-apple-darwin: g++ -O -ftree-vectorize -maltivec pr21933.cc pr21933.cc: In function 'void baz()': pr21933.cc:23: internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:750 Keith is looking into it. (probably a duplicate of PR21884 ?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21933
[Bug tree-optimization/21884] [4.1 regression] ICE with -ftree-vectorize
--- Additional Comments From dorit at il dot ibm dot com 2005-06-07 09:58 --- > I tried on powerpc-apple-darwin and on i686-pc-linux-gnu - couldn't reproduce > the failure correction - can't reproduce the failure on powerpc, but I do see the ICE on i686-pc-linux-gnu with both testcases (from comments #4 and #7). (I couldn't see the ICE before because I was accidently trying with a compiler configured with disable-checking before) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21884
[Bug c++/20563] [3.4/4.0/4.1 Regression] Infinite loop in diagnostic (and ice after error message)
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-07 09:33 --- Testing a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Keywords||monitored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20563
[Bug testsuite/21947] New: libmudflap C++ testsuite executed even if c++ is not enabled
I configured GCC HEAD (of 10 days ago) with "--enable-languages=c", then I bootstrapped it and ran "make -k check". In the test summary, I see failing mudflap C++ tests: FAIL: libmudflap.c++/fail24-frag.cxx (test for excess errors) WARNING: libmudflap.c++/fail24-frag.cxx compilation failed to produce executable FAIL: libmudflap.c++/pass27-frag.cxx (test for excess errors) WARNING: libmudflap.c++/pass27-frag.cxx compilation failed to produce executable FAIL: libmudflap.c++/pass28-frag.cxx (test for excess errors) WARNING: libmudflap.c++/pass28-frag.cxx compilation failed to produce executable FAIL: libmudflap.c++/pass31-frag.cxx (test for excess errors) WARNING: libmudflap.c++/pass31-frag.cxx compilation failed to produce executable FAIL: libmudflap.c++/pass41-frag.cxx (test for excess errors) WARNING: libmudflap.c++/pass41-frag.cxx compilation failed to produce executable [...] I don't think libmudflap.c++ should be run if C++ was not built. -- Summary: libmudflap C++ testsuite executed even if c++ is not enabled Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: giovannibajo at libero dot it CC: gcc-bugs at gcc dot gnu dot org,janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21947
[Bug debug/21946] Invalid DWARF2 debug info emitted
-- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||06/msg00312.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-06-07 08:41:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21946
[Bug debug/21946] New: Invalid DWARF2 debug info emitted
On ppc32:
/* { dg-options "-m32 -O2 -g" } */
extern int m;
struct A { unsigned char a; };
struct B { void *b; };
extern struct B *fn (int x);
struct C { struct C *c; };
static unsigned char *d;
typedef int (*T) (struct C *, void *);
struct C *foo (struct C *, T, void *);
int fx (struct C *, void *);
static struct C *
bar (struct C *x, unsigned char y, unsigned char z)
{
unsigned char v[2] = { y, z };
return foo (x, fx, v);
}
struct C *
baz (struct A *x, long long int y)
{
struct B *b;
struct C *c;
long long int z;
if (!(m == 4 || m == 2))
return 0;
z = x->a;
b = fn (z);
if (!b)
return 0;
c = (struct C *) b->b;
if (!c)
return 0;
if (m == 2 && z >= 240)
z -= 240;
else if (d)
z = d[z];
if (z == 255)
return 0;
return bar (c->c, z, y);
}
emits:
emits in one range for the y variable (DImode, i.e. 2 hard registers):
.4byte .LVL0-.Ltext0# Location list begin address (*.LLST2)
.4byte .LVL2-.Ltext0# Location list end address (*.LLST2)
.2byte 0x6 # Location expression size
.byte 0x55 # DW_OP_reg5
.byte 0x93 # DW_OP_piece
.byte 0x4 # uleb128 0x4
.byte 0x56 # DW_OP_reg6
.byte 0x93 # DW_OP_piece
.byte 0x4 # uleb128 0x4
.4byte .LVL2-.Ltext0# Location list begin address (*.LLST2)
.4byte .LVL3-.Ltext0# Location list end address (*.LLST2)
.2byte 0xb # Location expression size
.byte 0x55 # DW_OP_reg5
.byte 0x93 # DW_OP_piece
.byte 0x4 # uleb128 0x4
.byte 0x56 # DW_OP_reg6
.byte 0x93 # DW_OP_piece
.byte 0x4 # uleb128 0x4
.byte 0x93 # DW_OP_piece
.byte 0x8 # uleb128 0x8
.byte 0x56 # DW_OP_reg6
.byte 0x93 # DW_OP_piece
.byte 0x4 # uleb128 0x4
...
Similar problems occur even on little-endian targets, although less often:
0x8014ebb0..0x8014ebc2 [ 0] fbreg 160
[ 3] piece 4
[ 5] fbreg 164
[ 8] piece 4
0x8014ebc2..0x8014ebc4 [ 0] fbreg 160
0x8014ebc4..0x8014ebd6 [ 0] fbreg 160
[ 3] piece 8<-- BAD
[ 5] fbreg 164
[ 8] piece 4
(64-bit variable).
Not a regression, as -fvar-tracking is new in GCC 4.0, though one might say
that before we at least were not generating invalid debug info.
--
Summary: Invalid DWARF2 debug info emitted
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: jakub at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ppc-linux, x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21946
[Bug tree-optimization/21884] [4.1 regression] ICE with -ftree-vectorize
--- Additional Comments From stefaan dot deroeck at gmail dot com
2005-06-07 07:54 ---
Another testcase possibly, that triggers the fault on 20050605 with parameters
-march=pentium4 -O3 -ftree-vectorize, but not with -O2 or -O1. Bug 21933 seems
related but doesn't trigger with -O3 or -O2, but does with -O1 (the testcase in
this bug also doesn't use standard includes, so may be easier to track down)
#include
const int COUNT = 4;
struct A {
public:
A() {
for (int i=0; i {
void p1() {
clear();
insert(end(), A());
}
};
struct C {
B c1;
void p2();
};
void C::p2() {
c1.p1();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21884
[Bug middle-end/21728] [4.0/4.1 Regression] Nonlocal gotos between nested functions cause undefined labels in assembler output
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-07 07:53 --- I didn't even know we support multiple nesting like this... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21728
[Bug tree-optimization/21562] [4.0 Regression] Quiet bad codegen (unrolling + tail call interaction)
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-07 07:51 --- So is this fixed now? -- What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21562
[Bug tree-optimization/21859] ICE with -ftree-vectorize and -O2 or higher
--- Additional Comments From dorit at il dot ibm dot com 2005-06-07 07:50 --- This testcase doesn't get vectorized anymore, after my patch from http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02817.html: "pr21859.f90:6: note: not vectorized: redundant loop. no profit to vectorize. pr21859.f90:1: note: vectorized 0 loops in function." so it also doesn't ICE anymore. It might be that it's just avoiding the problem, but I also can't reproduce PR21831, which is a duplicate of this one, and which was not affected by my patch, so it might be that something else fixed the problem (don't know what). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21859
[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-07 07:49 --- You, like many DCE bugs before you, are now MINE! -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-06-05 23:10:25 |2005-06-07 07:49:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21847
[Bug tree-optimization/21847] [4.0/4.1 Regression] misscompiling of the following java code
--- Additional Comments From steven at gcc dot gnu dot org 2005-06-07 07:48 --- Re. comments #13 and #13, I _already_ said it should be "true" in comment #8 ;-) I'll commit the patch tonight. Mark, is this approval also for the 4.0 branch? -- What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21847
[Bug tree-optimization/21831] [4.1 Regression] gcc.dg/vect/vect-97.c fails
--- Additional Comments From dorit at il dot ibm dot com 2005-06-07 07:42 --- > I tried vect-97.c on power-pc and couldn't reproduce the problem. > I don't know if this means that the problem goes away with recent > patches or that it only occurs when vectorizing on ia64. I don't > have the ability to build and test on ia64. I don't see this failure anymore on i686-pc-linux-gnu and powerpc-apple-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21831
[Bug tree-optimization/21884] [4.1 regression] ICE with -ftree-vectorize
--- Additional Comments From dorit at il dot ibm dot com 2005-06-07 07:35 --- > I tried compiling x.ii on power-pc and couldn't reproduce the problem. > I don't know if this means that the problem goes away with recent > patches or that it only occurs when vectorizing on pentium. I currently > don't have the ability to build and test on pentium. I tried on powerpc-apple-darwin and on i686-pc-linux-gnu - couldn't reproduce the failure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21884
