[Bug c/29199] New: do not require -O for -Wunitialized
The man page of gcc states: -Wuninitialized Warn if an automatic variable is used without first being initial- ized or if a variable may be clobbered by a "setjmp" call. These warnings are possible only in optimizing compilation, because they require data flow information that is computed only when opti- mizing. If you don't specify -O, you simply won't get these warn- ings. This limitation, while understandable from the implementation standpoint, has a nasty consequence: one cannot use -Wunitialized and debug at the same time, because the -O very efficiently destroys information that is needed for debugging (such as being able to display local variables). The above triplets are for Apple's gcc 4.0.0, but that is irrelevant, the same thing happens on every gcc platform. In effect, this means that one needs to do two separate compiles while debugging a program: a "warnings" compile and a "debugging" compile. Suggestion: if the -Wunitialized is specified (and no -O), do just enough data flow analysis to perform the analysis required for the -Wunitialized, but abstain from doing anything that breaks debuggability. -- Summary: do not require -O for -Wunitialized Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jhi at iki dot fi GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29199
[Bug c/29199] do not require -O for -Wunitialized
--- Comment #1 from steven at gcc dot gnu dot org 2006-09-24 08:19 --- The choice to do things the way gcc does has been discussed many times over, and the conclusion always has been that either all warnings should be done in the front end, or dataflow analysis has to be used. The latter is what GCC does, and dataflow is indeed done only at -O1 and above. Doing "enough dataflow analysis" for -Wuninitialized wouldn't work because many of the uninitialized variables are discovered after optimization (e.g. removal of unreachable code). So you would end up with a compiler that reports different warnings at -O0 and -O1. That is even worse than the current situation. Since this has been discussed so many times on the gcc mailing lists, the current situation is the consensus (or rather status quo) that gcc developers are happy with. That means this bug will not be fixed. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29199
[Bug tree-optimization/28230] [4.2 Regression] -O2 -fwrapv miscompiles gcc, binutils, gzip.
--- Comment #13 from steven at gcc dot gnu dot org 2006-09-24 09:58 --- VRP bug. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug tree-optimization/28230] [4.2 Regression] -O2 -fwrapv miscompiles gcc, binutils, gzip.
--- Comment #14 from steven at gcc dot gnu dot org 2006-09-24 10:05 ---
Value ranges after VRP without -fwrapv:
e_1: VARYING
n_2: VARYING
e_3: VARYING
tn_4: VARYING
D.1875_5: [0, 65535] EQUIVALENCES: { } (0 elements)
bb_6: VARYING
D.1876_7: [0, +INF] EQUIVALENCES: { } (0 elements)
n_8: [0, +INF] EQUIVALENCES: { } (0 elements)
e_9: VARYING
e_11: VARYING
e_12: [n_2 + 1, +INF] EQUIVALENCES: { e_1 e_21 } (2 elements)
e_13: [e_3, e_3] EQUIVALENCES: { e_3 } (1 elements)
D.1878_14: [0, +INF] EQUIVALENCES: { } (0 elements)
n_15: [0, +INF] EQUIVALENCES: { } (0 elements)
D.1879_16: VARYING
SMT.5_17: VARYING
SMT.5_18: VARYING
e_21: [n_2 + 1, +INF] EQUIVALENCES: { e_1 } (1 elements)
Value ranges after VRP with -fwrapv:
e_1: VARYING
n_2: [0, 65534] EQUIVALENCES: { } (0 elements)
e_3: VARYING
tn_4: VARYING
D.1875_5: [0, 65535] EQUIVALENCES: { } (0 elements)
bb_6: VARYING
D.1876_7: [0, +INF] EQUIVALENCES: { } (0 elements)
n_8: [0, 65534] EQUIVALENCES: { } (0 elements)
e_9: VARYING
e_11: VARYING
e_12: [1, +INF] EQUIVALENCES: { e_1 e_21 } (2 elements)
e_13: [e_3, e_3] EQUIVALENCES: { e_3 } (1 elements)
D.1878_14: [0, +INF] EQUIVALENCES: { } (0 elements)
n_15: [1, 65534] EQUIVALENCES: { } (0 elements)
D.1879_16: VARYING
SMT.5_17: VARYING
SMT.5_18: VARYING
e_21: [1, +INF] EQUIVALENCES: { e_1 } (1 elements)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug tree-optimization/28230] [4.2 Regression] -O2 -fwrapv miscompiles gcc, binutils, gzip.
--- Comment #15 from steven at gcc dot gnu dot org 2006-09-24 10:08 ---
Significant difference:
n_15: [0, +INF] EQUIVALENCES: { } (0 elements) without -fwrapv
n_15: [1, 65534] EQUIVALENCES: { } (0 elements) with -fwrapv
With -fwrapv this results in:
Folding predicate n_15 != 0 to 1
Folded statement: if (n_15 != 0) goto ; else goto ;
into: if (1) goto ; else goto ;
which is the infinite loop here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug tree-optimization/28230] [4.2 Regression] -O2 -fwrapv miscompiles gcc, binutils, gzip.
--- Comment #16 from steven at gcc dot gnu dot org 2006-09-24 10:11 --- Actually looks like SCEV derives the wrong range. -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug objc/29200] New: %s substituted with "methods"/"selectors" can't be properly translated
In gcc/objc/objc-act.c there is this code: warning (0, "multiple %s named %<%c%s%> found", methods ? "methods" : "selectors", The strings substituted for the first %s are not available for translation, so this can not be properly translated. Even if they were, composing a sentence like this is not in general possible to do for an arbitrary language. -- Summary: %s substituted with "methods"/"selectors" can't be properly translated Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29200
[Bug target/29201] New: [4.2 Regression] ICE in create_recovery_block, at haifa-sched.c:3692 at -O3
ICE with -O3: [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O3 metacity-window.c metacity-window.c: In function 'meta_window_move_resize_internal': metacity-window.c:106: internal compiler error: in create_recovery_block, at haifa-sched.c:3692 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 metacity-window.c [EMAIL PROTECTED]:~$ gcc-4.1 -c -O3 metacity-window.c [EMAIL PROTECTED]:~$ -- Summary: [4.2 Regression] ICE in create_recovery_block, at haifa- sched.c:3692 at -O3 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29201
[Bug target/29201] [4.2 Regression] ICE in create_recovery_block, at haifa-sched.c:3692 at -O3
--- Comment #1 from tbm at cyrius dot com 2006-09-24 12:02 --- Created an attachment (id=12318) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12318&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29201
[Bug debug/29202] New: ICE in output_pubnames, at dwarf2out.c:7380
$ g++ posix_api.ii -c -gdwarf-2 -g2 -feliminate-dwarf2-dups -finline-functions internal compiler error: in output_pubnames, at dwarf2out.c:7380 -- Summary: ICE in output_pubnames, at dwarf2out.c:7380 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC target triplet: *-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29202
[Bug debug/29202] ICE in output_pubnames, at dwarf2out.c:7380
--- Comment #1 from pluto at agmk dot net 2006-09-24 12:54 --- Created an attachment (id=12319) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12319&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29202
[Bug fortran/20886] passing generic name as dummy argument
--- Comment #5 from pault at gcc dot gnu dot org 2006-09-24 14:55 --- Ooops, I forgot to clear this. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20886
[Bug debug/29132] [4.1 Regression] Mips exception handling broken.
--- Comment #8 from sayle at gcc dot gnu dot org 2006-09-24 15:56 --- Subject: Bug 29132 Author: sayle Date: Sun Sep 24 15:55:51 2006 New Revision: 117180 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117180 Log: PR debug/29132 Backport from mainline * dwarf2out.c (dwarf2out_begin_prologue): Initialise the current label, dw_fde_current_label, to be the start of the function, i.e. the same value as dw_fde_begin. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29132
[Bug target/29201] [4.2 Regression] ICE in create_recovery_block, at haifa-sched.c:3692 at -O3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29201
[Bug tree-optimization/29204] New: [4.1/4.2 Regression] duplicates existing symbol from inline assembler at -O
(sid)129:[EMAIL PROTECTED]: ~/delta/bin] gcc-3.4 -c -O3 mini.c
(sid)130:[EMAIL PROTECTED]: ~/delta/bin] gcc-4.0 -c -O3 mini.c
(sid)131:[EMAIL PROTECTED]: ~/delta/bin] gcc-4.1 -c -O3 mini.c
/tmp/cciWV4B7.s: Assembler messages:
/tmp/cciWV4B7.s:25: Error: symbol `L26' is already defined
/tmp/cciWV4B7.s:26: Error: symbol `L24' is already defined
zsh: exit 1 gcc-4.1 -c -O3 mini.c
(sid)132:[EMAIL PROTECTED]: ~/delta/bin] /usr/lib/gcc-snapshot/bin/gcc -c -O3
mini.c
/tmp/ccPxQMaA.s: Assembler messages:
/tmp/ccPxQMaA.s:25: Error: symbol `L26' is already defined
/tmp/ccPxQMaA.s:26: Error: symbol `L24' is already defined
zsh: exit 1 /usr/lib/gcc-snapshot/bin/gcc -c -O3 mini.c
(sid)133:[EMAIL PROTECTED]: ~/delta/bin]
(sid)133:[EMAIL PROTECTED]: ~/delta/bin] gcc-4.1 -c mini.c
(sid)134:[EMAIL PROTECTED]: ~/delta/bin] /usr/lib/gcc-snapshot/bin/gcc -c mini.c
(sid)135:[EMAIL PROTECTED]: ~/delta/bin] cat mini.c
extern unsigned long *p;
movinvr ()
{
int i;
unsigned long *pe;
unsigned long num;
for (i = 0; i < 2; i++)
{
asm __volatile__ ("jmp L26\n\t" ".p2align 4,,7\n\t" "L26:\n\t"
"L24:\n\t":"=D" (p):"D" (p), "S" (pe),
"b" (num):"eax", "ecx", "edx");
}
}
--
Summary: [4.1/4.2 Regression] duplicates existing symbol from
inline assembler at -O
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29204
[Bug c/29186] optimzation breaks floating point exception flag reading
--- Comment #12 from kreckel at ginac dot de 2006-09-24 16:51 --- (In reply to comment #11) > This is a TER bug then and I really doubt it can be fixed easy. It doesn't disappear with -fno-tree-ter, as I would assume if it were a TER bug. -- kreckel at ginac dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186
[Bug tree-optimization/29204] [4.1/4.2 Regression] duplicates existing symbol from inline assembler at -O
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-24 17:01 --- This is not a bug as asms can be duplicated even if they are volatile. The way to fix this is to use .1 and 1f lables. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29204
[Bug libgcj/29205] New: lib/pkgconfig/libgcj.pc needs to become version dependent
Currently, when installing two versions/copies of GCC into the same prefix, using suitable --libdir, --infodir and --program-suffix options, the *only* conflict, that is, the only file the second copy of GCC will overwrite, is lib/pkgconfig/libgcj.pc. One approach would be putting this into a version-specific subdirecty, such as --libdir, or name the file libgcj41.pc, libgcj42.pc, etc. -- Summary: lib/pkgconfig/libgcj.pc needs to become version dependent Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gerald at pfeifer dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29205
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #24 from pault at gcc dot gnu dot org 2006-09-24 17:31 --- Created an attachment (id=12320) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12320&action=view) Patch + testcases for allocatable components This version has all the known issues fixed and includes a number of testcases - some complete and some in 'draft' form. We are nearly there! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Attachment #12106|0 |1 is obsolete|| Attachment #12313|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug debug/29202] ICE in output_pubnames, at dwarf2out.c:7380
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-09-24 17:34 --- Reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29202
[Bug tree-optimization/25737] ACATS c974001 c974013 hang with struct aliasing
--- Comment #37 from ebotcazou at gcc dot gnu dot org 2006-09-24 18:23 --- > No, really, you don't seem to understand. > If you respect these DECL_NONADDRESSABLE_P or > TYPE_NONALIASED_COMPONENT flags, you are going to make them unaliased. > Your whole bug report is that they are not aliased and should be, and > that the loads and stores currently don't interfere but should. I think I understand your viewpoint: the name of TYPE_NONALIASED_COMPONENT and DECL_NONADDRESSABLE_P seems to imply than setting them would always result in less V_MAY_DEF's in the code. But... > Diego, the short summary is that Eric has some Ada testcases where we > end up with less V_MAY_DEF's than he thinks should. He believes that > respecting these flags, which specify you cannot form the address of a > certain component, etc, will somehow cause him to end up with more > aliasing and fix his testcase by anything other than luck. ...that's not so simple. If you look at how these flags work in GCC 3.x, you'll see that setting them has some impact on the alias sets used to access memory references, via can_address_p and the MEM_KEEP_ALIAS_SET_P flag. In GCC 4 dialect, this would result in different V_MAY_DEF's, not less. I'm not saying that this is a sane design or that we should try to replicate it in GCC 4, I'm just saying that for the time being struct aliasing totally overlooks this mechanism and doesn't work for Ada because of that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug target/28911] Cross compiler build for m68k--elf fails on x86_64-linux-gnu
--- Comment #8 from kazu at gcc dot gnu dot org 2006-09-24 18:47 --- Subject: Bug 28911 Author: kazu Date: Sun Sep 24 18:47:25 2006 New Revision: 117181 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117181 Log: gcc/ PR target/28911 * config/m68k/m68k.md (negsf2, negdf2, negxf2): Use -2147483647 - 1 instead of 0x8000. gcc/testsuite/ PR target/28911 * gcc.dg/pr28911.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr28911.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28911
[Bug target/28911] Cross compiler build for m68k--elf fails on x86_64-linux-gnu
--- Comment #9 from kazu at gcc dot gnu dot org 2006-09-24 18:48 --- Just checked in a patch. -- kazu at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28911
[Bug rtl-optimization/17264] [hppa] Missing address increment optimization for fp load/stores
--- Comment #1 from falk at debian dot org 2006-09-24 19:52 ---
For this test case:
void f(double *pds, double *pdd, unsigned long len) {
while (len >= 8*sizeof(double)) {
register double r1,r2,r3,r4;
r1 = *pds++;
r2 = *pds++;
r3 = *pds++;
r4 = *pds++;
*pdd++ = r1;
*pdd++ = r2;
*pdd++ = r3;
*pdd++ = r4;
}
}
gcc starting from 4.0 produces this:
.L3:
fldds -16(%r26),%fr22
fldds -8(%r26),%fr23
fldds 0(%r26),%fr24
fldds 8(%r26),%fr25
ldo 32(%r26),%r26
fstds %fr22,-16(%r25)
fstds %fr23,-8(%r25)
fstds %fr24,0(%r25)
fstds %fr25,8(%r25)
b .L3
which I suspect is actually better, since it avoids dependencies between the
loads. But I'm not familiar with hppa, can anybody comment?
--
falk at debian dot org changed:
What|Removed |Added
Known to fail||3.4.2 4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17264
[Bug rtl-optimization/17264] [hppa] Missing address increment optimization for fp load/stores
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-24
22:15 ---
Subject: Re: [hppa] Missing address increment optimization for fp load/stores
> For this test case:
>
> void f(double *pds, double *pdd, unsigned long len) {
> while (len >= 8*sizeof(double)) {
> register double r1,r2,r3,r4;
> r1 = *pds++;
> r2 = *pds++;
> r3 = *pds++;
> r4 = *pds++;
> *pdd++ = r1;
> *pdd++ = r2;
> *pdd++ = r3;
> *pdd++ = r4;
> }
> }
>
> gcc starting from 4.0 produces this:
>
> .L3:
> fldds -16(%r26),%fr22
> fldds -8(%r26),%fr23
> fldds 0(%r26),%fr24
> fldds 8(%r26),%fr25
> ldo 32(%r26),%r26
> fstds %fr22,-16(%r25)
> fstds %fr23,-8(%r25)
> fstds %fr24,0(%r25)
> fstds %fr25,8(%r25)
> b .L3
>
> which I suspect is actually better, since it avoids dependencies between the
> loads. But I'm not familiar with hppa, can anybody comment?
It looks close to optimal to me. The code is better than that generated
by 3.4.x or HP cc. Using the auto-increment forms would allow elimination
of the two ldo instructions to increment r25 and r26.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17264
[Bug target/29206] New: [4.2 regression] gcj-dbtool segfaults
[forwarded from http://bugs.debian.org/387875 ] [forwarded from http://bugs.debian.org/388505 ] gcj-dbtool segfaults on hppa-linux-gnu and arm-linux-gnu; arm doesn't have libjava support yet; the patches available from http://gcc.gnu.org/ml/java/2006-08/msg00123.html were used. rechecked both with a new 4.2 as a debian package and a vanilla upstream build. the installed gcj-dbtool crashes. I don't see the segfault, when gcj-dbtool is called during the build. GNU gdb 6.4.90-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "hppa-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so\ .1". (gdb) set args -n (gdb) run Starting program: /scratch/packages/gcc/4.2/tstinstall/bin/gcj-dbtool -n [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 17786)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 17786)] GC_push_all_eager (bottom=, top=0xc0345d48 "�4]HB�[EMAIL PROTECTED]���O��") at ../../../gcc-20060910/boehm-gc/mark.c:1468 1468q = *p; (gdb) p p $1 = (word *) 0xbfb45000 (gdb) p *p Cannot access memory at address 0xbfb45000 (gdb) bt #0 GC_push_all_eager (bottom=, top=0xc0345d48 "�4]HB�[EMAIL PROTECTED]���O��") at ../../../gcc-20060910/boehm-gc/mark.c:1468 #1 0x4214f74c in GC_push_all_stacks () at ../../../gcc-20060910/boehm-gc/pthread_stop_world.c:307 #2 0x42147d58 in GC_push_roots (all=16384, cold_gc_frame=0xc0345b48 "B��@") at ../../../gcc-20060910/boehm-gc/mark_rts.c:646 #3 0x42147438 in GC_mark_some (cold_gc_frame=0xc0345d48 "�4]HB�[EMAIL PROTECTED]���O��") at ../../../gcc-20060910/boehm-gc/mark.c:326 #4 0x4213d5cc in GC_stopped_mark (stop_func=0x4000) at ../../../gcc-20060910/boehm-gc/alloc.c:531 #5 0x4213d9c4 in GC_try_to_collect_inner (stop_func=0x4000) at ../../../gcc-20060910/boehm-gc/alloc.c:378 #6 0x42149718 in GC_init_inner () at ../../../gcc-20060910/boehm-gc/misc.c:789 #7 0x421499e4 in GC_init () at ../../../gcc-20060910/boehm-gc/misc.c:493 #8 0x42142f94 in GC_init_gcj_malloc (mp_index=-1078702080, mp=0xc0345d48) at ../../../gcc-20060910/boehm-gc/gcj_mlc.c:60 #9 0x4146df2c in _Jv_InitGC () at ../../../gcc-20060910/libjava/boehm.cc:503 #10 0x41414664 in _Jv_CreateJavaVM (vm_args=0x0) at ../../../gcc-20060910/libjava/prims.cc:1434 #11 0x41414e48 in _Jv_RunMain (vm_args=0x4000, klass=0x26770, name=0xc0345b48 "B��@", argc=2, argv=0xc034540c, is_jar=false) at ../../../gcc-20060910/libjava/prims.cc:1520 #12 0x414151c8 in _Jv_RunMain (klass=0xc0345d48, name=0xb , argc=1119747456, argv=, is_jar=false) at ../../../gcc-20060910/libjava/prims.cc:1593 #13 0x414151f4 in JvRunMain (klass=0xbfb45000, argc=1, argv=0x42bdfd80) at ../../../gcc-20060910/libjava/prims.cc:1599 #14 0x42f14338 in __libc_start_main () from /lib/libc.so.6 #15 0x00012610 in _start () at ../sysdeps/hppa/elf/start.S:84 -- Summary: [4.2 regression] gcj-dbtool segfaults Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC target triplet: hppa-linux-gnu arm-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206
[Bug target/29207] New: gij bus errors on hppa-linux-gnu and alpha-linux-gnu
[forwarded from http://bugs.debian.org/364819] when run on hppa-linux-gnu, gij produces unaligned memory accesses on hppa-linux-gnu (compiling the ecj.jar file), on alpha-linux-gnu compiling the libdb4.4 jar file(s) (Falk, please add the details). gij-4.1 \ -classpath build/bootstrap/ecj.jar:/usr/share/ant/lib/ant.jar \ org.eclipse.jdt.internal.compiler.batch.Main \ -bootclasspath /usr/share/java/libgcj-4.1.jar \ build/bin make: *** [build/stamp] Bus error -- Summary: gij bus errors on hppa-linux-gnu and alpha-linux-gnu Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org GCC target triplet: hppa-linux-gnu alpha-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29207
[Bug c++/29208] New: C++: Warn about unchecked use of pointers
There should be a warning about unchecked use of pointers in C++. For example:
void f(T * const x) {
}
--
Summary: C++: Warn about unchecked use of pointers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sigra at home dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29208
[Bug c++/29208] C++: Warn about unchecked use of pointers
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-24 23:29 --- What do you mean by unchecked use of pointers? You example is useless as the function does nothing and even does not compile as T is undeclared. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29208
[Bug c++/29208] C++: Warn about unchecked use of pointers
--- Comment #2 from sigra at home dot se 2006-09-24 23:29 ---
Sorry, accidentally hit commit too early. Try again:
There should be a warning about unchecked use of pointers in C++. For example:
void f(T * const x) {
x->something... // x might be 0, warn.
}
void f(T * const x) {
if (x) x->something... // this is OK, no need to warn
}
This warning would help to find places where the programmer has made a very
common kind of error; he has made the function take a pointer parameter when he
should have used a reference instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29208
[Bug c++/29208] C++: Warn about unchecked use of pointers
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-24 23:37 --- This would require dataflow to get correct and it is not that useful as some functions require non zero pointers and those should crash instead of having null pointer checks on them. And using references is not always the answer as some functions need to be able to be used from C which does not have references. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29208
[Bug rtl-optimization/17264] [hppa] Missing address increment optimization for fp load/stores
--- Comment #3 from randolph at tausq dot org 2006-09-24 23:48 --- Subject: Re: [hppa] Missing address increment optimization for fp load/stores >> gcc starting from 4.0 produces this: >> >> .L3: >> fldds -16(%r26),%fr22 >> fldds -8(%r26),%fr23 >> fldds 0(%r26),%fr24 >> fldds 8(%r26),%fr25 >> ldo 32(%r26),%r26 >> fstds %fr22,-16(%r25) >> fstds %fr23,-8(%r25) >> fstds %fr24,0(%r25) >> fstds %fr25,8(%r25) >> b .L3 >> >> which I suspect is actually better, since it avoids dependencies between the >> loads. But I'm not familiar with hppa, can anybody comment? > > It looks close to optimal to me. The code is better than that generated > by 3.4.x or HP cc. Using the auto-increment forms would allow elimination > of the two ldo instructions to increment r25 and r26. Yeah, this looks pretty good. I've been told that not using the autoincrement forms might be even better as it avoids interlocks between successive instructions. The ldo insn just gets pipelined so it doesn't necessarily slow things down. I'll mark this bug as resolved. thanks randolph -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17264
[Bug rtl-optimization/17264] [hppa] Missing address increment optimization for fp load/stores
--- Comment #4 from tausq at debian dot org 2006-09-24 23:49 --- Fixed in gcc-4.x -- tausq at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17264
[Bug c++/29208] C++: Warn about unchecked use of pointers
--- Comment #4 from sigra at home dot se 2006-09-24 23:57 --- (In reply to comment #3) > some functions require non zero pointers and those should crash instead of > having null pointer checks on them. And using references is not always the > answer as some functions need to be able to be used from C which does not > have references. Using references is almost always the answer. There are many projects that are in pure C++ without any need to be compatible with C, and it would be helpful for them to be able to enable such a warning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29208
Re: [Bug tree-optimization/25737] ACATS c974001 c974013 hang with struct aliasing
On 24 Sep 2006 18:23:41 -, ebotcazou at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: --- Comment #37 from ebotcazou at gcc dot gnu dot org 2006-09-24 18:23 --- > No, really, you don't seem to understand. > If you respect these DECL_NONADDRESSABLE_P or > TYPE_NONALIASED_COMPONENT flags, you are going to make them unaliased. > Your whole bug report is that they are not aliased and should be, and > that the loads and stores currently don't interfere but should. I think I understand your viewpoint: the name of TYPE_NONALIASED_COMPONENT and DECL_NONADDRESSABLE_P seems to imply than setting them would always result in less V_MAY_DEF's in the code. But... The name, and all the documentation, which say they cannot be addressed, which means they cannot be pointed to by any pointer, which means they are unaliased. > Diego, the short summary is that Eric has some Ada testcases where we > end up with less V_MAY_DEF's than he thinks should. He believes that > respecting these flags, which specify you cannot form the address of a > certain component, etc, will somehow cause him to end up with more > aliasing and fix his testcase by anything other than luck. ...that's not so simple. If you look at how these flags work in GCC 3.x, you'll see that setting them has some impact on the alias sets used to access memory references, via can_address_p and the MEM_KEEP_ALIAS_SET_P flag. In GCC 4 dialect, this would result in different V_MAY_DEF's, not less. If so, then you've both hacked around something more funamental, and the documentation of all these flags don't actually match what you really mean. I'm not saying that this is a sane design or that we should try to replicate it in GCC 4, I'm just saying that for the time being struct aliasing totally overlooks this mechanism and doesn't work for Ada because of that. Okay, and i'm saying i don't plan on accepting fixes that appear to hack around well accepted infrastructure to try to fix symptoms. Really. That's all. I'm not going to approve patches that randomly skip fields because it seems to get the right result sometimes. If you want to try to explain what all this is actually trying to do, i'm happy to work with you to come up with a sane solution.
[Bug tree-optimization/25737] ACATS c974001 c974013 hang with struct aliasing
--- Comment #38 from dberlin at gcc dot gnu dot org 2006-09-25 01:27 --- Subject: Re: ACATS c974001 c974013 hang with struct aliasing On 24 Sep 2006 18:23:41 -, ebotcazou at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #37 from ebotcazou at gcc dot gnu dot org 2006-09-24 18:23 > --- > > No, really, you don't seem to understand. > > If you respect these DECL_NONADDRESSABLE_P or > > TYPE_NONALIASED_COMPONENT flags, you are going to make them unaliased. > > Your whole bug report is that they are not aliased and should be, and > > that the loads and stores currently don't interfere but should. > > I think I understand your viewpoint: the name of TYPE_NONALIASED_COMPONENT > and DECL_NONADDRESSABLE_P seems to imply than setting them would always > result in less V_MAY_DEF's in the code. But... > The name, and all the documentation, which say they cannot be addressed, which means they cannot be pointed to by any pointer, which means they are unaliased. > > Diego, the short summary is that Eric has some Ada testcases where we > > end up with less V_MAY_DEF's than he thinks should. He believes that > > respecting these flags, which specify you cannot form the address of a > > certain component, etc, will somehow cause him to end up with more > > aliasing and fix his testcase by anything other than luck. > > ...that's not so simple. If you look at how these flags work in GCC 3.x, > you'll see that setting them has some impact on the alias sets used to access > memory references, via can_address_p and the MEM_KEEP_ALIAS_SET_P flag. > In GCC 4 dialect, this would result in different V_MAY_DEF's, not less. If so, then you've both hacked around something more funamental, and the documentation of all these flags don't actually match what you really mean. > > I'm not saying that this is a sane design or that we should try to replicate > it in GCC 4, I'm just saying that for the time being struct aliasing totally > overlooks this mechanism and doesn't work for Ada because of that. Okay, and i'm saying i don't plan on accepting fixes that appear to hack around well accepted infrastructure to try to fix symptoms. Really. That's all. I'm not going to approve patches that randomly skip fields because it seems to get the right result sometimes. If you want to try to explain what all this is actually trying to do, i'm happy to work with you to come up with a sane solution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug debug/29202] ICE in output_pubnames, at dwarf2out.c:7380
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-25 03:19 ---
reduced testcase:
template struct s
{
charT imp() const;
};
template charT s::imp() const
{
static const int masks[20] = {0};
}
__extension__ extern template char s::imp() const;
int regcompA(void)
{
s t;
t.imp();
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-09-25 03:19:34
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29202
[Bug debug/29202] [4.1/4.2 Regression] ICE with external template and const data in the template
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Known to work||3.4.0 Summary|ICE in output_pubnames, at |[4.1/4.2 Regression] ICE |dwarf2out.c:7380|with external template and ||const data in the template Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29202
[Bug debug/29132] [4.1 Regression] Mips exception handling broken.
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-25 03:23 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29132
[Bug c++/20599] variadic template support
--- Comment #9 from gdr at integrable-solutions dot net 2006-09-25 03:38 --- Subject: Re: variadic template support "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | For the record, personally and for what is worth my personal opinion | in the compiler area, I have nothing against adding to the compiler | -std=c++0x We should have -std=c++2003 and -std=c++0x. However, care must be exercise about what is included in both options. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20599
[Bug c++/20599] variadic template support
--- Comment #10 from fang at csl dot cornell dot edu 2006-09-25 03:46 --- Subject: Re: variadic template support > | For the record, personally and for what is worth my personal opinion > | in the compiler area, I have nothing against adding to the compiler > | -std=c++0x > > We should have -std=c++2003 and -std=c++0x. However, care must be > exercise about what is included in both options. > > -- Gaby So what will "-ansi -pedantic-errors" use? c++98, 2003, or 0x? Fang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20599
[Bug objc/29200] %s substituted with "methods"/"selectors" can't be properly translated
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-25 04:31 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2006-09-25 04:31:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29200
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2006-09-25 05:09 --- Paul, The current patch builds fine on Darwin PPC and shows no regressions in the gfortran testsuite at either -m32 or -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug fortran/20541] TR 15581: ALLOCATABLE components
--- Comment #26 from jvdelisle at gcc dot gnu dot org 2006-09-25 05:53 --- Paul, OK here too. i686-linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20541
[Bug c++/29189] Error during CPP build of Mozilla
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-09-25 06:07 --- bl [EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29189
