/usr/src/lib/libmagic/../../contrib/file/apprentice.c:735: internal compiler error: in extract_insn, at recog.c:2083
cc -DHAVE_CONFIG_H -DCOMPILE_ONLY -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -o mkmagic /usr/src/lib/libmagic/../../contrib/file/apprentice.c /usr/src/lib/libmagic/../../contrib/file/funcs.c /usr/src/lib/libmagic/../../contrib/file/magic.c /usr/src/lib/libmagic/../../contrib/file/print.c /usr/src/lib/libmagic/../../contrib/file/apprentice.c: In function `parse': /usr/src/lib/libmagic/../../contrib/file/apprentice.c:735: error: unrecognizable insn: (insn 362 361 363 59 /usr/src/lib/libmagic/../../contrib/file/apprentice.c:510 (UnKnown Unknown) -1 (nil) (nil)) /usr/src/lib/libmagic/../../contrib/file/apprentice.c:735: internal compiler error: in extract_insn, at recog.c:2083 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 Stop in /usr/src/lib/libmagic. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. root: uname -a FreeBSD pc.domain.com 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Wed Mar 22 20:44:32 EET 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IBsec i386 root: gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.4 [FreeBSD] 20050518 Best regards, Valentin ChernoZemsky __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[Bug c/27016] New: ARM optimizer produces severely suboptimal code
The compiler creates extremely bad code for the ARM target.
Consider the following source file:
--- SNIP ---
unsigned int code_in_ram[100];
void testme(void)
{
unsigned int *p_rom, *p_ram, *p_end, len;
extern unsigned int _ram_erase_sector_start;
extern unsigned int _ram_erase_sector_end;
p_ram = code_in_ram;
p_rom = &_ram_erase_sector_start;
len = ((unsigned int)&_ram_erase_sector_end
- (unsigned int)&_ram_erase_sector_start) / sizeof(unsigned int);
for (p_rom = &_ram_erase_sector_start, p_end = &_ram_erase_sector_end;
p_rom < p_end;) {
*p_ram++ = *p_rom++;
}
}
--- SNIP ---
Compiled with arm-elf-gcc -mcpu=arm7tdmi -S -Os testme.c, we get the following
code:
--- SNIP ---
.file "testme.c"
.text
.align 2
.global testme
.type testme, %function
testme:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r1, .L6
ldr r2, .L6+4
@ lr needed for prologue
b .L2
.L3:
ldr r3, [r1], #4
str r3, [r2, #-4]
.L2:
ldr r3, .L6+8
cmp r1, r3
add r2, r2, #4
bcc .L3
bx lr
.L7:
.align 2
.L6:
.word _ram_erase_sector_start
.word code_in_ram
.word _ram_erase_sector_end
.size testme, .-testme
.comm code_in_ram,400,4
.ident "GCC: (GNU) 4.1.0"
--- SNIP ---
Even a cursory examination reveals that it would be a lot better to write:
ldr r1, .L6
ldr r2, .L6+4
ldr r0, .L6+8
b .L2
.L3:
ldr r3, [r1], #4
str r3, [r2], #4
.L2:
cmp r1, r0
bcc .L3
bx lr
This code would be one instruction shorter overall , and two instructions less
in the loop. The way
gcc-4.1.0 refuses to use post-indexed addressing for the store is especially
bizzare, since it does use
post-indexed addressing for the preceeding load. Gcc 3.4.3 does not exhibit
this behaviour; it compiles
the above code to:
ldr r2, .L6
ldr r0, .L6+4
cmp r2,r0
ldr r1, .L6
movcs pc,lr
.L4:
ldr r2,[r2],#4
cmp r2, r0
str r3,[r1],#4
bcc .L4
mov pc,lr
While not perfect either, this also only has 4 instructions in the loop.
--
Summary: ARM optimizer produces severely suboptimal code
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Eric dot Doenges at betty-tv dot com
GCC host triplet: powerpc-apple-darwin8.5.0
GCC target triplet: arm-elf-unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27016
[Bug tree-optimization/26763] [4.1 Regression] wrong final value of induction variable calculated
--- Comment #11 from patchapp at dberlin dot org 2006-04-04 08:15 --- Subject: Bug number PR26763 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00126.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26763
[Bug middle-end/27016] ARM optimizer produces severely suboptimal code
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-04 08:16 --- This code is undefined: len = ((unsigned int)&_ram_erase_sector_end - (unsigned int)&_ram_erase_sector_start) / sizeof(unsigned int); That is obviously undefined as taking the difference between two pointers which are not in the same array is undefined code. Even the comparision: p_rom < p_end; is undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27016
[Bug c++/27017] New: Debug information for static local class members are not emitted
Given this program, compiled with 'g++ -ggdb3 program.C' and then run under gdb. when I get to f(int)::s::g(int) then I can't examine any local variables nor any arguments. When I rerun the compiler using 'g++ -ggdb3 -S program.C' and examine the generated assembler there are no references to neither argument2 nor variable2, but the string argument1 do show up. -- Summary: Debug information for static local class members are not emitted Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at magfr dot user dot lysator dot liu dot se 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=27017
[Bug c++/27017] Debug information for static local class members are not emitted
--- Comment #1 from gcc at magfr dot user dot lysator dot liu dot se 2006-04-04 08:36 --- Created an attachment (id=11198) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11198&action=view) Testcase - program.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27017
[Bug debug/27017] Debug information for static local class members are not emitted
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-04 08:44 --- Works with stabs. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |debug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27017
[Bug debug/27017] [4.0/4.1/4.2 Regression] Debug information for static local class members are not emitted
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-04 08:52 --- Confirmed, it fails with the dwarf2 output format (I don't know why). Anyways I am marking this as a regression as this is a visible regression to the user as using -g from one version to the next should be improvements and not regressing -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu |dwarf2 Known to fail|3.3.6 4.0.3 4.1.0 4.2.0 |3.3.6 4.0.3 4.1.0 4.2.0 ||3.2.3 Known to work||3.0.4 Last reconfirmed|-00-00 00:00:00 |2006-04-04 08:52:40 date|| Summary|Debug information for static|[4.0/4.1/4.2 Regression] |local class members are not |Debug information for static |emitted |local class members are not ||emitted Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27017
[Bug middle-end/27018] New: fold-const.c:associate_trees produces constants with overflow flag set
Consider associate_trees being called with (gdb) call debug_tree(t1) constant invariant 4294967295> (gdb) call debug_tree(t2) constant invariant 1> (gdb) call debug_tree(type) constant invariant 32> unit size constant invariant 4> align 32 symtab 0 alias set -1 precision 32 min max pointer_to_this > (gdb) print code $15 = PLUS_EXPR we return via return fold_build2 (code, type, fold_convert (type, t1), fold_convert (type, t2)); where fold_build2 gets called with (gdb) down #1 0x083b401f in fold_build2_stat (code=PLUS_EXPR, type=0xb7c9b284, op0=0xb7d26558, op1=0xb7c8ba38) at /space/rguenther/src/svn/gcc/gcc/fold-const.c:11134 11134 tem = fold_binary (code, type, op0, op1); (gdb) call debug_tree(op0) constant invariant public static overflow -1> (gdb) call debug_tree(op1) constant invariant 1> -- Summary: fold-const.c:associate_trees produces constants with overflow flag set Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27018
[Bug middle-end/27018] fold-const.c:associate_trees produces constants with overflow flag set
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-04 08:56 --- Why do you think this is a bug? OVERFLOW now has only a meaning to the front-ends like it should be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27018
[Bug middle-end/27018] fold-const.c:associate_trees produces constants with overflow flag set
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-04 08:59 --- Where is the testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27018
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #26 from karol at mikronika dot com dot pl 2006-04-04 09:00 --- Does anybody from gcc developers resolve this old bug issue at any finished time?! This is nearly 2 years old bug!!! Greets, Karol (In reply to comment #25) > (In reply to comment #24) > > Test case doesn't work with gcc 3.3.6 and the latest cvs binutils > > (2.16.91.20051230) > > > > Testcase work when I used binutils 2.12.1. > > My OS box: Slackware 10.2 (i686) > -- karol at mikronika dot com dot pl changed: What|Removed |Added CC||karol at mikronika dot com ||dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug middle-end/27018] fold-const.c:associate_trees produces constants with overflow flag set
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-04 09:05 --- Since there is not enough info at where this really goes wrong, closing as invalid as producing a constant with the overflow flag set is not a bug unless you can produce a diagnostic. -- 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=27018
[Bug c/27007] Missed optimization of comparison with 'limited range'
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-04-04 09:09 --- Confirmed. -- rguenth 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-04-04 09:09:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27007
[Bug middle-end/27016] ARM optimizer produces severely suboptimal code
--- Comment #2 from Eric dot Doenges at betty-tv dot com 2006-04-04 09:13 --- (In reply to comment #1) > This code is undefined: > len = ((unsigned int)&_ram_erase_sector_end > - (unsigned int)&_ram_erase_sector_start) / sizeof(unsigned int); > > That is obviously undefined as taking the difference between two pointers > which > are not in the same array is undefined code. > > Even the comparision: > p_rom < p_end; > is undefined. > In the code I took this snippet from, _ram_erase_sector_start and _ram_erase_sector_end are symbols generated by the linker at the start and the end of a special segment which I need to copy to ram, so I would argue that these pointers do in fact refer to the same "array" (in this case, the "array" is the entire flash memory). However, none of this should affect the decision to use (or not to use) the post-indexed addressing mode. If I replace the for loop with a for (len = 100; len > 0; --len), the quality of the generated code actually degrades even further: ldr r2, .L7 ldr r1, .L7+4 @ lr needed for prologue .L2: ldr r3, [r1, #-4] str r3, [r2, #-4] ldr r3, .L7+8 add r2, r2, #4 cmp r2, r3 add r1, r1, #4 bne .L2 bx lr While I thinks it's nifty that gcc recognizes that it doesn't need to keep the len variable, but instead uses p_ram to determine when the loop is finished, I also think it's pretty brain-dead that it won't use post-indexed addressing for either the ldr or str in the loop. And why it thinks it needs to load the constant end address to compare against every time inside the loop instead of once into a scratch register outside the loop is anyone's guess. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27016
[Bug c++/27019] New: [4.1/4.2 regression] ICE with designated initializers
The following invalid code snippet causes an ICE since GCC 4.1.0:
==
struct A
{
int i;
int z[1];
};
A a = { z:{} };
==
bug.cc:7: sorry, unimplemented: non-trivial designated initializers not
supported
bug.cc:7: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Before we got:
bug.cc:7: sorry, unimplemented: non-trivial labeled initializers
bug.cc:7: error: initializer for scalar variable requires one element
--
Summary: [4.1/4.2 regression] ICE with designated initializers
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27019
[Bug target/26776] A stack frame can't be recovered when using large auto variable area.
--- Comment #5 from nickc at gcc dot gnu dot org 2006-04-04 09:18 --- Subject: Bug 26776 Author: nickc Date: Tue Apr 4 09:18:38 2006 New Revision: 112659 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112659 Log: PR target/26775 PR target/26776 * config/m32r/m32r.c (m32r_output_function_epilogue): Case for a large stack frame at epilogue. Use fp to recover a stack pointer for alloca function at epilogue. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/m32r/initfini.c branches/gcc-4_0-branch/gcc/config/m32r/m32r.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26776
[Bug target/26775] a stack pointer is not recovered correctly when using alloca.
--- Comment #6 from nickc at gcc dot gnu dot org 2006-04-04 09:18 --- Subject: Bug 26775 Author: nickc Date: Tue Apr 4 09:18:38 2006 New Revision: 112659 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112659 Log: PR target/26775 PR target/26776 * config/m32r/m32r.c (m32r_output_function_epilogue): Case for a large stack frame at epilogue. Use fp to recover a stack pointer for alloca function at epilogue. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/m32r/initfini.c branches/gcc-4_0-branch/gcc/config/m32r/m32r.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26775
[Bug c/27020] New: [4.0/4.1/4.2 regression] ICE on invalid array size
The following invalid code snippet causes an ICE since GCC 4.0.1: === int x[1/0]; === bug.c:1: warning: division by zero bug.c:1: internal compiler error: Segmentation fault Please submit a full bug report, [etc.] Before we got: bug.c:1: warning: division by zero bug.c:1: error: storage size of 'x' isn't constant -- Summary: [4.0/4.1/4.2 regression] ICE on invalid array size Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, monitored Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27020
[Bug target/26775] a stack pointer is not recovered correctly when using alloca.
--- Comment #7 from nickc at gcc dot gnu dot org 2006-04-04 09:20 --- Subject: Bug 26775 Author: nickc Date: Tue Apr 4 09:20:35 2006 New Revision: 112660 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112660 Log: PR target/26775 PR target/26776 * config/m32r/m32r.c (m32r_output_function_epilogue): Case for a large stack frame at epilogue. Use fp to recover a stack pointer for alloca function at epilogue. Modified: branches/gcc-3_4-branch/gcc/ChangeLog branches/gcc-3_4-branch/gcc/config/m32r/m32r.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26775
[Bug target/26776] A stack frame can't be recovered when using large auto variable area.
--- Comment #6 from nickc at gcc dot gnu dot org 2006-04-04 09:20 --- Subject: Bug 26776 Author: nickc Date: Tue Apr 4 09:20:35 2006 New Revision: 112660 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112660 Log: PR target/26775 PR target/26776 * config/m32r/m32r.c (m32r_output_function_epilogue): Case for a large stack frame at epilogue. Use fp to recover a stack pointer for alloca function at epilogue. Modified: branches/gcc-3_4-branch/gcc/ChangeLog branches/gcc-3_4-branch/gcc/config/m32r/m32r.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26776
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #30 from bonzini at gnu dot org 2006-04-04 09:20 --- Zdenek: are you using walk_data->interesting_blocks to not visit PHI nodes on non-interesting blocks? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug c/27020] [4.0/4.1/4.2 regression] ICE on invalid array size
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-04 09:24 --- Confirmed, the ICE is in the same place as PR 25161 is. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25161 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-04 09:24:36 date|| Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27020
[Bug c++/27019] [4.1/4.2 regression] ICE with designated initializers
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-04 09:29 --- We have a null type here, it really should have been error_mark_node. -- 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 Last reconfirmed|-00-00 00:00:00 |2006-04-04 09:29:50 date|| Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27019
[Bug fortran/27021] New: Problem with nearest(tiny(o),-1.0)/2.0
The following program program chop real o, t, td, tu, x, y o = 1. t = tiny(o) td = nearest(t,-1.0) x = td/2.0 y = nearest(tiny(o),-1.0)/2.0 print *, x, y, x - y end program chop gives 5.8774718E-39 5.8774704E-39 1.4012985E-45 on OSX 10.3.9 and GNU Fortran 95 (GCC) 4.2.0 20060401 (experimental). I.e, nearest(tiny(o),-1.0)/2.0 does not give the same result as td = nearest(t,-1.0) x = td/2.0 Dominique -- Summary: Problem with nearest(tiny(o),-1.0)/2.0 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27021
[Bug c/27022] New: ICE in build_polynomial_chrec, at tree-chrec.h / mpfr-2.2.0
Trying to compile MPFR 2.2 fails with today's gcc with file mpfr-2.2.0/div.c gcc -g -O2 -ffloat-store -MT -MD -MP -MF -c div.c -o div.o div.c: In function 'mpfr_div': div.c:125: internal compiler error: in build_polynomial_chrec, at tree-chrec.h:108 gcc -v /src/gcc/configure --enable-languages=c,c++,fortran --enable-checking --enable-cxa_atexit Thread-Modell: posix gcc-Version 4.2.0 20060403 (experimental) tree -- Summary: ICE in build_polynomial_chrec, at tree-chrec.h / mpfr- 2.2.0 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: c dot lemmen at fz-juelich dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27022
[Bug fortran/27021] Problem with nearest(tiny(o),-1.0)/2.0
--- Comment #1 from c dot lemmen at fz-juelich dot de 2006-04-04 10:05 --- on x86-linux gfortran 5.8774718E-39 5.8774704E-39 1.4012985E-45 f90 5.8774718E-39 5.8774718E-39 0.000E+00 pgf905.8774718E-39 5.8774718E-39 0.000 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27021
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #31 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-04-04 10:20 ---
Subject: Re: [4.2 Regression] Repeated SSA update during loop header copying
> Zdenek: are you using walk_data->interesting_blocks to not visit PHI nodes on
> non-interesting blocks?
No, I am keeping lists of interesting phi nodes in each basic block (see
the patch below -- without the time measurement code, of course). Using
just interesting_blocks might be simpler, I will try how much that
helps.
Index: tree-into-ssa.c
===
*** tree-into-ssa.c (revision 112625)
--- tree-into-ssa.c (working copy)
*** Boston, MA 02110-1301, USA. */
*** 47,52
--- 47,53
#include "domwalk.h"
#include "ggc.h"
#include "params.h"
+ #include "toplev.h"
/* This file builds the SSA form for a function as described in:
R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K. Zadeck. Efficiently
*** get_default_def_for (tree sym)
*** 777,782
--- 778,800
return ddef;
}
+ /* Marks phi node PHI in basic block BB for rewrite. */
+
+ static void
+ mark_phi_for_rewrite (basic_block bb, tree phi)
+ {
+ VEC (tree, heap) *phis_to_rewrite;
+
+ if (REWRITE_THIS_STMT (phi))
+ return;
+
+ phis_to_rewrite = bb->aux;
+ if (!phis_to_rewrite)
+ phis_to_rewrite = VEC_alloc (tree, heap, 10);
+ REWRITE_THIS_STMT (phi) = 1;
+ VEC_safe_push (tree, heap, phis_to_rewrite, phi);
+ bb->aux = phis_to_rewrite;
+ }
/* Insert PHI nodes for variable VAR using the iterated dominance
frontier given in PHI_INSERTION_POINTS. If UPDATE_P is true, this
*** insert_phi_nodes_for (tree var, bitmap p
*** 846,852
/* Mark this PHI node as interesting for update_ssa. */
REGISTER_DEFS_IN_THIS_STMT (phi) = 1;
! REWRITE_THIS_STMT (phi) = 1;
}
}
--- 864,870
/* Mark this PHI node as interesting for update_ssa. */
REGISTER_DEFS_IN_THIS_STMT (phi) = 1;
! mark_phi_for_rewrite (bb, phi);
}
}
*** replace_use (use_operand_p use_p, tree u
*** 1497,1502
--- 1515,1522
SET_USE (use_p, rdef);
}
+ unsigned long upi_cas_useful, upi_cas_total;
+ unsigned upi_calls, upi_did;
/* Visit all the successor blocks of BB looking for PHI nodes. For
every PHI node found, check if any of its arguments is in
*** rewrite_update_phi_arguments (struct dom
*** 1509,1527
{
edge e;
edge_iterator ei;
FOR_EACH_EDGE (e, ei, bb->succs)
{
tree phi;
! for (phi = phi_nodes (e->dest); phi; phi = PHI_CHAIN (phi))
{
tree arg;
use_operand_p arg_p;
! /* Skip PHI nodes that are not marked for rewrite. */
! if (!REWRITE_THIS_STMT (phi))
! continue;
arg_p = PHI_ARG_DEF_PTR_FROM_EDGE (phi, e);
arg = USE_FROM_PTR (arg_p);
--- 1529,1556
{
edge e;
edge_iterator ei;
+ unsigned i;
+ unsigned ohi, olo;
+ unsigned long long cas;
+ bool did = false;
+
+ rdtsc(ohi, olo);
+ upi_calls++;
FOR_EACH_EDGE (e, ei, bb->succs)
{
tree phi;
+ VEC (tree, heap) *phis_to_rewrite = e->dest->aux;
! if (!phis_to_rewrite)
! continue;
!
! for (i = 0; VEC_iterate (tree, phis_to_rewrite, i, phi); i++)
{
tree arg;
use_operand_p arg_p;
! gcc_assert (REWRITE_THIS_STMT (phi));
arg_p = PHI_ARG_DEF_PTR_FROM_EDGE (phi, e);
arg = USE_FROM_PTR (arg_p);
*** rewrite_update_phi_arguments (struct dom
*** 1534,1539
--- 1563,1569
/* When updating a PHI node for a recently introduced
symbol we may find NULL arguments. That's why we
take the symbol from the LHS of the PHI node. */
+ did = true;
replace_use (arg_p, SSA_NAME_VAR (PHI_RESULT (phi)));
}
else
*** rewrite_update_phi_arguments (struct dom
*** 1541,1555
tree sym = DECL_P (arg) ? arg : SSA_NAME_VAR (arg);
if (symbol_marked_for_renaming (sym))
! replace_use (arg_p, sym);
else if (is_old_name (arg))
! replace_use (arg_p, arg);
}
if (e->flags & EDGE_ABNORMAL)
SSA_NAME_OCCURS_IN_ABNORMAL_PHI (USE_FROM_PTR (arg_p)) = 1;
}
}
}
--- 1571,1599
tree sym = DECL_P (arg) ? arg : SSA_NAME_VAR (arg);
if (symbol_marked_for_renaming (sym))
! {
! did = true;
! replace_use (arg_p, sym);
! }
else if (is_old_name (arg))
! {
! did = true;
! replace_use (arg_p, arg);
! }
}
if (e->flags & EDGE_ABNORMAL)
SSA_NAME_OCCURS_IN_ABNORMAL
[Bug bootstrap/27023] New: cannot build with GNU make 3.81
After update GNU make from 3.80 up to 3.81 i cannot build gcc 4.0.2,
4.0.3 and 4.1.0 on Solaris 9/05 sparc whith same error:
% tar xvf gcc-4.0.3.tar.bz2
% mkdir objdir && cd objdir
% bash ../configure --enable-threads=solaris --enable-languages=c,c++
--enable-shared=libstdc++ --disable-multilib --disable-nls
--disable-libstdcxx-pch sparc64-sun-solaris2.9
% make
...
rm -f ./libgcov.a
ar rc ./libgcov.a libgcc/./_gcov.o libgcc/./_gcov_merge_add.o
libgcc/./_gcov_me
rge_single.o libgcc/./_gcov_merge_delta.o libgcc/./_gcov_fork.o
libgcc/./_gcov_e
xecl.o libgcc/./_gcov_execlp.o libgcc/./_gcov_execle.o
libgcc/./_gcov_execv.o li
bgcc/./_gcov_execvp.o libgcc/./_gcov_execve.o
ranlib ./libgcov.a
make[2]: Leaving directory `/export/home/devel/build/gcc-4.0.3/objdir/gcc'
echo timestamp > stmp-multilib
make[1]: Leaving directory `/export/home/devel/build/gcc-4.0.3/objdir/gcc'
/bin/bash: -c: line 5: syntax error: unexpected end of file
make: *** [multilib.out] Error 2
Makefile:
multilib.out: maybe-all-gcc
@r=`${PWD_COMMAND}`; export r; \
echo "Checking multilib configuration..."; \
$(CC_FOR_TARGET) --print-multi-lib > multilib.tmp 2> /dev/null ; \
$(SHELL) $(srcdir)/move-if-change multilib.tmp multilib.out ; \
after change to:
multilib.out: maybe-all-gcc
@r=`${PWD_COMMAND}`; export r; \
echo "Checking multilib configuration..."; \
$(CC_FOR_TARGET) --print-multi-lib > multilib.tmp 2> /dev/null ; \
$(SHELL) $(srcdir)/move-if-change multilib.tmp multilib.out
it work fine for me!
Thanks a lot!
--
Summary: cannot build with GNU make 3.81
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tiamat at komi dot mts dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27023
[Bug bootstrap/27023] cannot build with GNU make 3.81
--- Comment #1 from tiamat at komi dot mts dot ru 2006-04-04 12:10 --- Created an attachment (id=11199) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11199&action=view) proposed patch proposed patch for buld gcc 4.0.2, 4.0.3 and 4.1.0 with gnu make 3.81 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27023
[Bug c/27022] ICE in build_polynomial_chrec, at tree-chrec.h / mpfr-2.2.0
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-04 12:19 --- Please attach preprocessed source of div.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27022
[Bug c++/11159] erroneous warning in copy ctor with virtual inheritance
--- Comment #10 from roman dot fietze at telemotive dot de 2006-04-04
12:26 ---
The following snippet also gives me errors, and here, as a developer, I did all
I could do:
-
#include
class MyStream : public std::ostringstream
{
public:
inline MyStream() : std::ostringstream() {}
inline MyStream(const MyStream &ms) : std::ostringstream()
{ std::ostringstream::str(ms.str()); }
};
-
The result, as before:
$ gcc --version
gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
...
$ g++ -W -c mystream.cc
mystream.cc: In copy constructor `MyStream::MyStream(const MyStream&)':
mystream.cc:13: warning: base class `struct std::basic_ios >' should be explicitly initialized in the copy
constructor
I do not have access to std::basic_ios from MyStream. Solution here?
--
roman dot fietze at telemotive dot de changed:
What|Removed |Added
CC||roman dot fietze at
||telemotive dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11159
[Bug bootstrap/27023] cannot build with GNU make 3.81
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-04-04 13:11 --- Thanks for reporting the problem and the patch, I'll take care of it. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-04 13:11:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27023
[Bug tree-optimization/26830] [4.2 Regression] Repeated SSA update during loop header copying
--- Comment #32 from bonzini at gnu dot org 2006-04-04 14:29 --- Zdenek, I'm sure you can construct an example where my simple minded approach still blows up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26830
[Bug java/27024] New: Implement URLConnection.getFileNameMap
Freenet needs this to determine Content-Type for the static files it serves over the web. Classpath appears to have a working version, although some common extensions (css, ico) are notably missing. -- Summary: Implement URLConnection.getFileNameMap Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: taral at taral dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27024
[Bug java/27025] New: ICE on simple initializer
class z {
static final String ALGORITHM = "Rijndael";
static final double VERSION = 0.1;
static final String FULL_NAME = ALGORITHM + " ver. " + VERSION;
}
compiled with:
% gcj-4.1 -C z.java
z.java: In class 'z':
z.java: In method '()':
z.java:4: internal compiler error: Segmentation fault
---
Debian package 4.1.0-1
configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --enable-checking=release x86_64-linux-gnu
--
Summary: ICE on simple initializer
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: taral at taral dot net
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27025
[Bug java/27025] ICE on simple initializer
--- Comment #1 from taral at taral dot net 2006-04-04 14:45 --- This doesn't happen with gcj -c, only with gcj -C. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27025
[Bug libstdc++/26926] double vs. long double libmath export confusion
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-04-04 14:49 --- libstdc++ should not be exporting things that are unnecessary. this isn't an "uncorrect" code issue, it's a "shouldn't be doing that" issue -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26926
[Bug c/26774] [4.0/4.1/4.2 Regression] Out of memory compiling 9-line Delta-reduced Linux kernel driver msp3400.c
--- Comment #5 from carlos at codesourcery dot com 2006-04-04 15:00 --- Created an attachment (id=11201) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11201&action=view) Fix parser error handling The patch fixes this issue. No regressions on i686-pc-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26774
[Bug c/26774] [4.0/4.1/4.2 Regression] Out of memory compiling 9-line Delta-reduced Linux kernel driver msp3400.c
--- Comment #6 from carlos at codesourcery dot com 2006-04-04 15:01 --- I'll submit the patch to gcc-patches and check it in when approved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26774
[Bug tree-optimization/27022] ICE in build_polynomial_chrec, at tree-chrec.h / mpfr-2.2.0
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-04 15:08 --- Please read http://gcc.gnu.org/bugs.html as requested :) and attach the preprocessed source. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Component|c |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27022
[Bug libgcj/25414] should update rmic
--- Comment #3 from aph at gcc dot gnu dot org 2006-04-04 15:08 --- Subject: Bug 25414 Author: aph Date: Tue Apr 4 15:08:51 2006 New Revision: 112667 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112667 Log: 2006-04-03 Archit Shah <[EMAIL PROTECTED]> PR java/25414 * gnu/java/rmi/rmic/CompilerProcess.java (computeTypicalArguments): Add classpath argument. * gnu/java/rmi/rmic/Compile_gcj.java (computeArguments): Adjust caller. * gnu/java/rmi/rmic/Compile_jikes.java (computeArguments): Likewise. * gnu/java/rmi/rmic/Compile_kjc.java (computeArguments): Likewise. * gnu/java/rmi/rmic/Compiler.java (getClasspath, setClasspath): New. * gnu/java/rmi/rmic/RMIC.java: Set classpath for compiler, call mkdirs for destination directory, correct handling of superclasses and interfaces of the remote class, correct handling of exceptions declared by remote methods. Modified: branches/gcc-4_1-branch/libjava/ChangeLog branches/gcc-4_1-branch/libjava/gnu/java/rmi/rmic/Compile_gcj.java branches/gcc-4_1-branch/libjava/gnu/java/rmi/rmic/Compile_jikes.java branches/gcc-4_1-branch/libjava/gnu/java/rmi/rmic/Compile_kjc.java branches/gcc-4_1-branch/libjava/gnu/java/rmi/rmic/Compiler.java branches/gcc-4_1-branch/libjava/gnu/java/rmi/rmic/CompilerProcess.java branches/gcc-4_1-branch/libjava/gnu/java/rmi/rmic/RMIC.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25414
[Bug c/27026] New: unexpected creation of altivec instructions
This has been bugging me for already more then a year, but tonight I found some
time to debug it.
I'm running mandrake-ppc on a G3 processor. As is common for most distro's,
"-mcpu=7450 -maltivec" are the standard compile options, even although my
processor cannot execute altivec instructions. In general, this works
perfectly. Except for this case:
./mplayer -ao alsa /opt/shared/music/test.mp3
MPlayer dev-CVS-060323-17:34-4.0.3 (C) 2000-2006 MPlayer Team
CPU: PowerPC
Selected audio codec: [mad] afm: libmad (libMAD MPEG layer 1-2-3)
==
Illegal instruction
backtrace:
#0 0x10110bd0 in init ()
#1 0x10107e0c in init_best_audio_out ()
#2 0x1006ca4c in main ()
this is init in ao_alsa.c of the mplayer internal copy of libao2.
lets continue:
0x10110b9c :stwur1,-432(r1)
0x10110ba0 :mflrr0
0x10110ba4 :stw r26,408(r1)
0x10110ba8 : stw r27,412(r1)
0x10110bac : stw r28,416(r1)
0x10110bb0 : stw r29,420(r1)
0x10110bb4 : stw r31,428(r1)
0x10110bb8 : stw r0,436(r1)
0x10110bbc : mr r31,r1
0x10110bc0 : stw r3,360(r31)
0x10110bc4 : stw r4,364(r31)
0x10110bc8 : stw r5,368(r31)
0x10110bcc : stw r6,372(r31)
0x10110bd0 : vxorv0,v0,v0
0x10110bd4 : li r0,32
0x10110bd8 : stvxv0,r31,r0
0x10110bdc : vxorv0,v0,v0
vxor? That's altivec. Weird
Adding -O -g got rid of the bug. Strangely, adding -O2 or -O3 seemed to fix the
issue as well (normally, no -O option is specified).
I played a bit with the sources (see the *.i file I'll add in a subsequent
post).
This is the problematic area of ao_alsa.c:
int init(int rate_hz, int channels, int format, int flags)
{
int err;
int block;
//int block_ad = â–ˆ
strarg_t device;
snd_pcm_uframes_t bufsize;
snd_pcm_uframes_t boundary;
opt_t subopts[] = {
{"block", OPT_ARG_BOOL, &block, NULL},
{"device", OPT_ARG_STR, &device, (opt_test_f)str_maxlen},
{NULL}
};
Checkout the //int block_ad = â–ˆ which I added inthere myself.
If I uncomment this, the program works perfectly!
But the line in question doesn't do anything at all since block_ad is not used
anywhere (I originally tried to substitute &block for block_add because I
iterativelly found that &block was the problematic thingy).
I guess just getting the address of block puts the compiler straight about what
it is supposed to do:)
I hope this provides enough info to find and fix the problem.
Danny
--
Summary: unexpected creation of altivec instructions
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: obiwan at mailmij dot org
GCC host triplet: ppc
GCC target triplet: ppc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27026
[Bug java/27025] ICE on simple initializer
-- aph at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-04 15:23:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27025
[Bug c/27026] unexpected creation of altivec instructions
--- Comment #1 from obiwan at mailmij dot org 2006-04-04 15:25 --- Created an attachment (id=11202) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11202&action=view) preproc. sources Result of: cc -save-temps -c -I../libvo -I../../libvo -I/usr/X11R6/include -mcpu=7450 -maltivec -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/lzo -I. -I.. -I/usr/include/artsc -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include-I/usr/include/lzo -D_REENTRANT -I/usr/include/SDL -D_REENTRANT -I/usr/X11R6/include -o ao_alsa.o ao_alsa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27026
[Bug target/27026] unexpected creation of altivec instructions
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-04 15:27 --- -maltivec is enables altivec instructions everywhere so this is not a bug. -maltivec does not just enable explict use of altivec but also implicate uses which this is via memcpy. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27026
[Bug libstdc++/26875] Array allocator use count is shared between array_allocator instances
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-04-04 15:27 --- Created an attachment (id=11203) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11203&action=view) fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26875
[Bug libstdc++/26875] Array allocator use count is shared between array_allocator instances
--- Comment #8 from bkoz at gcc dot gnu dot org 2006-04-04 15:28 --- Here's a fix that seems to work. Agree with Paolo, this should go into mainline and gcc-4.1 -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26875
[Bug c/27012] visibility attribute should not be permitted on local variables
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-04 15:37 --- Confirmed, this should be an error and not just a warning. -- 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-04-04 15:37:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27012
[Bug target/27026] unexpected creation of altivec instructions
--- Comment #3 from obiwan at mailmij dot org 2006-04-04 15:42 --- whoa stop, since when is this? The man page is not particullary clear on this. And where is it documented? This is going to upset many people since now we basically need to compile everything without -maltivec just to be backwards compatible on older hardware? And even more strange, mplayer is the only app that I have ever crashing with an illegal instruction... If what you say is true, can there be an option for excluding implicit use of altivec? d. -- obiwan at mailmij dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27026
[Bug target/27026] unexpected creation of altivec instructions
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-04 15:48 --- The change started to happen in 4.0.x but since the docs say: Generate code that uses AltiVec instructions, Which means implicated uses. There is no option, you compile the altivec code in a seperate file. People will have the same issue with -msse on x86 too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27026
[Bug other/26966] linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #13 from kgardas at objectsecurity dot com 2006-04-04 15:53 --- Subject: Re: linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols Hello, I've rebuild todays trunk and configured it as: $ gcc -v Using built-in specs. Target: i386-unknown-openbsd3.9 Configured with: /home/karel/svn/gcc/trunk/configure --prefix=/home/karel/usr/local/gcc-trunk-20060404 --enable-shared --enable-threads --enable-languages=c++,objc --disable-checking --disable-nls --disable-werror Thread model: posix gcc version 4.2.0 20060404 (experimental) $ now I've tested your ObjC test and compilation fails with: $ gcc test.m /tmp//ccsP4264.o(.text+0x18): In function `main': : undefined reference to `objc_get_class' /tmp//ccsP4264.o(.text+0x2c): In function `main': : undefined reference to `objc_msg_lookup' /tmp//ccsP4264.o(.text+0x62): In function `__objc_gnu_init': : undefined reference to `__objc_exec_class' /tmp//ccsP4264.o(.data+0x40): undefined reference to `__objc_class_name_Object' collect2: ld returned 1 exit status $ as it seems gcc does not link against libobjc automatically I also tried this: $ gcc test.m -lobjc and I finally got some POSIX threading related undefined symbols: $ gcc test.m -lobjc /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: warning: strcpy() is almost always misused, please use strlcpy() /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: warning: sprintf() is often misused, please use snprintf() /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_cond_signal' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_attr_destroy' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_create' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_getspecific' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_attr_init' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_exit' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_key_delete' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_cond_broadcast' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_once' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_key_create' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_cond_init' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_mutex_unlock' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_self' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_mutex_destroy' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_mutex_lock' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_cond_wait' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_mutex_trylock' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_cond_destroy' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_mutex_init' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `pthread_attr_setdetachstate' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0: undefined reference to `sched_yield' /home/karel/usr/local/gcc-trunk-20060404/lib/gcc/i386-unknown-openbsd3.9/4.2.0/../../../libobjc.so.2.0:
[Bug other/26966] linking of C++ app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-04-04 15:56 --- Thanks for testing, now it might be easier to understand the issue is not purely a libstdc++ one but a gthr-posix.c one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-04 15:56:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug other/26966] linking of C++/ObjC app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
--- Comment #15 from kgardas at objectsecurity dot com 2006-04-04 15:57 --- I've changed summary from "C++ app" to "C++/ObjC app" to better reflect the issue. -- kgardas at objectsecurity dot com changed: What|Removed |Added Summary|linking of C++ app fail on |linking of C++/ObjC app fail |OpenBSD 3.9 due POSIX |on OpenBSD 3.9 due POSIX |threading unresolved symbols|threading unresolved symbols http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug target/27026] unexpected creation of altivec instructions
--- Comment #5 from obiwan at mailmij dot org 2006-04-04 16:03 --- hmm, ok. Seems I was wrong on the fact that -maltivec is the default for all apps. Only certain programs use it. It probably means that we (the few remaining maintainers of mdv-ppc) have to find a satisfying fix for those. Well, thanks for the info! danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27026
[Bug java/27025] ICE on simple initializer
--- Comment #2 from tromey at gcc dot gnu dot org 2006-04-04 16:11 --- Note that this works with 4.0 and fails with svn head. So, it is a regression. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27025
[Bug libgcj/27024] Implement URLConnection.getFileNameMap
-- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-04 16:11:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27024
[Bug libgcj/27027] New: thread cancellation and native Eclipse
In native Eclipse, cancelling builds does not work. Presumably this is a libgcj problem with thread cancellation. It would dramatically improve the user experience in native Eclipse if thread cancellation were properly supported. -- Summary: thread cancellation and native Eclipse Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fitzsim at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27027
[Bug java/27028] New: Eclipse Update Manager throws ConcurrentModificationExceptions
While using the Eclipse update manager to install software, it sometimes fails with a ConcurrentModificationException. This seems to only happen some of the time but most often on the first attempt at installing Subclipse (ie. when it does the entire download, verification, etc.). Here's how to install Subclipse: http://subclipse.tigris.org/install.html -- Summary: Eclipse Update Manager throws ConcurrentModificationExceptions Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: overholt at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27028
[Bug other/27029] New: Outdated texinfo.tex included
Running "make dvi" fails with TeTex 3.0 and texinfo 4.8 because the included texinfo.tex produces *.pdf files per default: Output written on g77.pdf (370 pages, 2232006 bytes). Transcript written on g77.log. cp: cannot stat `./g77.dvi': No such file or directory ... Output written on gcj.pdf (53 pages, 285114 bytes). Transcript written on gcj.log. cp: cannot stat `./gcj.dvi': No such file or directory and so on... The gcc-included texinfo.tex is dated 2003-12-21.10, replacing it with a version from texinfo-4.8 dated 2004-11-25.16 produces working *.dvi files. -- Summary: Outdated texinfo.tex included Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: spiralvoice at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27029
[Bug java/27025] ICE on simple initializer
--- Comment #3 from aph at gcc dot gnu dot org 2006-04-04 17:12 --- Created an attachment (id=11204) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11204&action=view) PR java/27025: ICE on simple initializer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27025
[Bug c/26993] ICE on invalid code with weakref
-- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-04 17:37:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26993
[Bug tree-optimization/18527] cannot determine number of iterations for loops with <=
--- Comment #12 from pbrook at gcc dot gnu dot org 2006-04-04 17:40 --- Subject: Bug 18527 Author: pbrook Date: Tue Apr 4 17:40:00 2006 New Revision: 112675 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112675 Log: 2006-04-04 Paul Brook <[EMAIL PROTECTED]> Backport form mainline. gcc/ 2006-01-14 Zdenek Dvorak <[EMAIL PROTECTED]> * tree-ssa-loop-niter.c (number_of_iterations_cond): Split into several functions. (number_of_iterations_ne, number_of_iterations_lt_to_ne, assert_no_overflow_lt, assert_loop_rolls_lt, number_of_iterations_lt, number_of_iterations_le): New functions. (number_of_iterations_special): Removed. (number_of_iterations_exit): Do not use number_of_iterations_special. * tree.c (unsigned_type_for): Always return integer type. 2005-01-06 Zdenek Dvorak <[EMAIL PROTECTED]> PR tree-optimization/18527 * tree-ssa-loop-niter.c (number_of_iterations_cond, number_of_iterations_special, number_of_iterations_exit): Move base and step of an iv to a single structure. Add no_overflow flag, and use it in # of iterations analysis. * tree-scalar-evolution.c (analyze_scalar_evolution_in_loop): Add folded_casts argument. (simple_iv): Pass base and step in a structure. Set no_overflow flag. (scev_const_prop): Add argument to analyze_scalar_evolution_in_loop. Evaluate expensiveness of computing # of iterations instead of the final expression. * tree-scalar-evolution.h (affine_iv): New structure. (simple_iv): Declaration changed. * tree-chrec.c (chrec_apply): Handle chrecs containing symbols. * tree-ssa-loop-ivopts.c (determine_biv_step, find_givs_in_stmt_scev, find_givs_in_stmt): Changed due to simple_iv change. gcc/testsuite/ * gcc.c-torture/execute/loop-ivopts-3.c: New test. 2005-01-14 Zdenek Dvorak <[EMAIL PROTECTED]> * gcc.dg/tree-ssa/pr19210-1.c: Update outcome. Add new test loop. * gcc.dg/tree-ssa/pr19210-2.c: Ditto. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/loop-ivopts-3.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/pr19210-1.c branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/tree-ssa/pr19210-2.c branches/gcc-4_1-branch/gcc/tree-chrec.c branches/gcc-4_1-branch/gcc/tree-scalar-evolution.c branches/gcc-4_1-branch/gcc/tree-scalar-evolution.h branches/gcc-4_1-branch/gcc/tree-ssa-loop-ivopts.c branches/gcc-4_1-branch/gcc/tree-ssa-loop-niter.c branches/gcc-4_1-branch/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18527
[Bug c/26993] ICE on invalid code with weakref
--- Comment #1 from aoliva at gcc dot gnu dot org 2006-04-04 17:41 --- Created an attachment (id=11205) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11205&action=view) Patch that fixes the bug This is the patch I'm testing to fix the ICE. At the time I added weakref support, using extern rather than static, we didn't fail this way; it was the change that made weakrefs static that broke it, so 4.1 is not affected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26993
[Bug c/26993] ICE on invalid code with weakref
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-04 17:43 --- Shouldn't we error out instead of warning? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26993
[Bug c/27030] New: Warning instead of error with weakref on local functions (also wrong warning message at that)
Take:
int f(void)
{
__typeof(f) __gthrw_f __attribute__ ((__weakref__("f")));
}
--
Currently we get:
t.c: In function 'f':
t.c:3: warning: 'alias' attribute ignored
I don't see an alias attribute in the orginal code at all.
--
Summary: Warning instead of error with weakref on local functions
(also wrong warning message at that)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27030
[Bug c/27030] Warning instead of error with weakref on local functions (also wrong warning message at that)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-04 17:50 --- 4.1.0 fails the same way. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.0 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27030
[Bug other/27029] Outdated texinfo.tex included
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-04 17:56 --- 3.4.6 was the last release of the 3.4.x series, can you try 4.0.2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27029
[Bug java/27025] ICE on simple initializer
--- Comment #4 from aph at gcc dot gnu dot org 2006-04-04 18:17 --- David Daney pointed out the part of the JLS that forbids my solution. I'll work on another patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27025
[Bug libgcj/27031] New: native Eclipse uses too much memory on startup, sometimes
I can't really be more specific than this, but sometimes when I start up native Eclipse it uses all available memory immediately. I'll attach a screenshot of top when it happens. -- Summary: native Eclipse uses too much memory on startup, sometimes Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fitzsim at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27031
[Bug libgcj/27031] native Eclipse uses too much memory on startup, sometimes
--- Comment #1 from fitzsim at redhat dot com 2006-04-04 18:46 --- Created an attachment (id=11206) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11206&action=view) Screenshot of top when gij uses all memory when running eclipse. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27031
[Bug other/26966] [4.1/4.2 Regression] linking of C++/ObjC app fail on OpenBSD 3.9 due POSIX threading unresolved symbols
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|linking of C++/ObjC app fail|[4.1/4.2 Regression] linking |on OpenBSD 3.9 due POSIX|of C++/ObjC app fail on |threading unresolved symbols|OpenBSD 3.9 due POSIX ||threading unresolved symbols Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26966
[Bug testsuite/27032] New: gcc.c-torture/compile/pr23237.c fails
gcc.c-torture/compile/pr23237.c (test for excess errors) is FAILing on
hppa2.0w-hp-hpux11.11 at all optimization levels. The error is "section
attributes are not supported for this target". I don't know why the {
dg-require-effective-target named_sections } is not being effective, but that
it isn't is presumably the problem.
--
Summary: gcc.c-torture/compile/pr23237.c fails
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jsm28 at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27032
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #12 from tromey at gcc dot gnu dot org 2006-04-04 19:07 --- Created an attachment (id=11207) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11207&action=view) reduced test case I tried to reduce this to a C test case suitable for inclusion in libffi. I've attached this. Unfortunately on the ia64 machine I tried, it does not fail. I haven't looked to see what I might have done wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug testsuite/27033] New: g++.dg/eh/spbp.C (test for excess errors) fails
FAIL: g++.dg/eh/spbp.C (test for excess errors) is present on hppa2.0w-hp-hpux11.11: "error: target system does not support the "dwarf-2" debug format". hppa*-*-hpux* needs skipping just like AIX. -- Summary: g++.dg/eh/spbp.C (test for excess errors) fails Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27033
[Bug target/27034] New: [4.2 Regression] gcc.dg/20021014-1.c (test for excess errors) fails
FAIL: gcc.dg/20021014-1.c (test for excess errors) appeared on hppa64-hp-hpux11.11 on trunk between revisions 112223 (20060320, PASSes) and 112281 (20060322, FAILs). ld: Unsatisfied symbol "pthread_mutex_unlock" in file /scratch/gcc/nightly-2006-04-03-mainline/hppa64-hp-hpux11.11/build_gcc/install/lib/gcc/hppa64-hp-hpux11.11/4.2.0/libgcc_eh.a[unwind-dw2-fde.o] ld: Unsatisfied symbol "pthread_mutex_lock" in file /scratch/gcc/nightly-2006-04-03-mainline/hppa64-hp-hpux11.11/build_gcc/install/lib/gcc/hppa64-hp-hpux11.11/4.2.0/libgcc_eh.a[unwind-dw2-fde.o] -- Summary: [4.2 Regression] gcc.dg/20021014-1.c (test for excess errors) fails Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27034
[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)
--- Comment #3 from jsm28 at gcc dot gnu dot org 2006-04-04 19:22 --- Also seen on hppa2.0w-hp-hpux11.11, appearing between revisions 112080 and 112130: FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors) FAIL: gcc.dg/torture/pr24626-1.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/pr24626-1.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/pr24626-1.c -Os (test for excess errors) FAIL: gcc.dg/torture/pr24626-2.c -O2 (test for excess errors) FAIL: gcc.dg/torture/pr24626-2.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/pr24626-2.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/pr24626-3.c -O2 (test for excess errors) FAIL: gcc.dg/torture/pr24626-3.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/pr24626-3.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/pr24626-3.c -Os (test for excess errors) -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|hppa-unknown-linux-gnu |hppa*-*-* GCC host triplet|hppa-unknown-linux-gnu |hppa*-*-* GCC target triplet|hppa-unknown-linux-gnu |hppa*-*-* Last reconfirmed|-00-00 00:00:00 |2006-04-04 19:22:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
[Bug testsuite/27033] g++.dg/eh/spbp.C (test for excess errors) fails
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-04 19:26 --- Actually there really should be a g++.dg/debug/dwarf2 like there is a gcc.dg/debug/dwarf2. -- 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-04-04 19:26:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27033
[Bug target/27034] [4.2 Regression] gcc.dg/20021014-1.c (test for excess errors) fails
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org GCC target triplet||hppa64-hp-hpux11.11 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27034
[Bug libgcj/27028] Eclipse Update Manager throws ConcurrentModificationExceptions
--- Comment #1 from mckinlay at redhat dot com 2006-04-04 19:52 ---
I couldn't reproduce this when installing Subclipse, but after installing it
and subsequently trying to disable it, I reproducably get the following crash:
java.util.ConcurrentModificationException.ConcurrentModificationException()
([EMAIL PROTECTED])
at
../../../libjava/classpath/java/util/ConcurrentModificationException.java:80
80{
(gdb) bt
#0 java.util.ConcurrentModificationException.ConcurrentModificationException()
([EMAIL PROTECTED])
at
../../../libjava/classpath/java/util/ConcurrentModificationException.java:80
#1 0x0349ded2 in java.util.HashMap$HashIterator.hasNext() ([EMAIL PROTECTED])
at ../../../libjava/classpath/java/util/HashMap.java:856
#2 0x01efadb8 in
org::eclipse::update::internal::model::ConfigurationPolicyModel::remove () from
/usr/lib/gcj/eclipse/org.eclipse.update.core_3.1.2.jar.so
#3 0x01efb2df in
org::eclipse::update::internal::model::ConfigurationPolicyModel::addUnconfiguredFeatureReference
()
from /usr/lib/gcj/eclipse/org.eclipse.update.core_3.1.2.jar.so
#4 0x01ec56bb in
org::eclipse::update::internal::core::ConfigurationPolicy::unconfigure () from
/usr/lib/gcj/eclipse/org.eclipse.update.core_3.1.2.jar.so
The relevent Eclipse code is:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.update.core/src/org/eclipse/update/internal/model/ConfigurationPolicyModel.java?rev=1.25&content-type=text/vnd.viewcvs-markup
/**
*
*/
private boolean remove(FeatureReferenceModel feature, Map list) {
URL featureURL = feature.getURL();
boolean found = false;
Iterator iter = list.keySet().iterator();
while (iter.hasNext() && !found) {
FeatureReferenceModel element = (FeatureReferenceModel)
iter.next();
if
(UpdateManagerUtils.sameURL(element.getURL(),featureURL)) {
list.remove(element);
found = true;
}
}
return found;
}
This code is buggy: it is directly modifying an underlying collection (list)
while an iterator on that collection (iter) is active. This is not allowed
according to the J2SE documentation:
"The iterators returned by all of this class's "collection view methods" are
fail-fast: if the map is structurally modified at any time after the iterator
is created, in any way except through the iterator's own remove or add methods,
the iterator will throw a ConcurrentModificationException. "
If this code works on Sun's implementation, then it would appear that Sun's
implementation does not conform with their own spec.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27028
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #13 from wilson at tuliptree dot org 2006-04-04 20:22 --- Subject: Re: Wrong parsing of doubles when interpreted on ia64 On Tue, 2006-04-04 at 12:07, tromey at gcc dot gnu dot org wrote: > I tried to reduce this to a C test case suitable for inclusion > in libffi. I've attached this. Unfortunately on the ia64 machine > I tried, it does not fail. I haven't looked to see what I > might have done wrong. I was able to write a testcase that showed the problem. I based it on float1.c, changed to accept and return a double, initialize input arg with a denorm value, and using an exact check instead of a delta check after the call. The delta checks don't work for a denorm. Since I am not doing any arithmetic, we should get the same value back. I see I forgot to change the comment though, that will have to be fixed. This testcase reproduces the bug for me, and is fixed by my unfinished patch. I'll attach my testcase to the PR. I think your testcase doesn't work because you aren't actually calling a function that takes and return double arguments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #14 from wilson at gcc dot gnu dot org 2006-04-04 20:24 --- Created an attachment (id=11208) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11208&action=view) proposed testcase, based on float1.c This reproduces the denorm failure for me with unpatched sources, and worked with my proposed unfinished patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug other/27029] gcc3.4/make dvi creates .pdf instead of .dvi files
--- Comment #2 from spiralvoice at hotmail dot com 2006-04-04 20:28 --- gcc3.4/make dvi creates .pdf instead of .dvi files -- spiralvoice at hotmail dot com changed: What|Removed |Added Summary|Outdated texinfo.tex|gcc3.4/make dvi creates .pdf |included|instead of .dvi files http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27029
[Bug other/27029] gcc3.4/make dvi creates .pdf instead of .dvi files
--- Comment #3 from spiralvoice at hotmail dot com 2006-04-04 20:29 --- Please ignore the last comment;-) make dvi produces correct output in gcc-4.0.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27029
[Bug classpath/27028] Eclipse Update Manager throws ConcurrentModificationExceptions
--- Comment #2 from mckinlay at redhat dot com 2006-04-04 20:34 --- The difference between Sun's and Classpath's implementation appears to be that Classpath will check for Concurrent Modification on both hasNext() and next() calls, while Sun's implementation only checks next() calls. -- mckinlay at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mckinlay at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Component|libgcj |classpath Ever Confirmed|0 |1 Product|gcc |classpath Last reconfirmed|-00-00 00:00:00 |2006-04-04 20:34:07 date|| Target Milestone|--- |0.91 Version|4.1.0 |0.90 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27028
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #15 from andreast at gcc dot gnu dot org 2006-04-04 20:46 --- Great, a libffi test case! Would you mind adding a reference to the PR in the test case header and adjust the 'int i' in main to 'unsigned int i'? If you feel ok with the test case then please commit to trunk. Thanks, Andreas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/27031] native Eclipse uses too much memory on startup, sometimes
--- Comment #2 from bkonrath at redhat dot com 2006-04-04 20:59 --- I get the same behaviour about 25% of the time on my machine. Traking this down is on my list of things to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27031
[Bug bootstrap/27023] cannot build with GNU make 3.81
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-04-04 21:03 --- Subject: Bug 27023 Author: ebotcazou Date: Tue Apr 4 21:03:05 2006 New Revision: 112679 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112679 Log: PR bootstrap/27023 * Makefile.tpl (multilib.out): Remove trailing backslash. * Makefile.in: Regenerate. Modified: branches/gcc-4_1-branch/ChangeLog branches/gcc-4_1-branch/Makefile.in branches/gcc-4_1-branch/Makefile.tpl -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27023
[Bug other/27029] gcc3.4/make dvi creates .pdf instead of .dvi files
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-04 21:03 --- So 4.0.x works? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27029
[Bug bootstrap/27023] cannot build with GNU make 3.81
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-04-04 21:04 --- Subject: Bug 27023 Author: ebotcazou Date: Tue Apr 4 21:04:37 2006 New Revision: 112680 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112680 Log: PR bootstrap/27023 * Makefile.tpl (multilib.out): Remove trailing backslash. * Makefile.in: Regenerate. Modified: branches/gcc-4_0-branch/ChangeLog branches/gcc-4_0-branch/Makefile.in branches/gcc-4_0-branch/Makefile.tpl -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27023
[Bug libgcj/27031] native Eclipse uses too much memory on startup, sometimes
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-04 21:05 --- The easy way to track this down is using a memory profiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27031
[Bug bootstrap/27023] cannot build with GNU make 3.81
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-04-04 21:07 --- Fixed on 4.0 and 4.1 branch, mainline is not affected. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||04/msg00164.html Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27023
[Bug fortran/27035] New: present doesn't work on array
[EMAIL PROTECTED] cpu2006-465e]$ cat foo.f90 program main call foo (5) end program main subroutine foo(n, a) integer :: n integer, dimension(5), optional :: a print *, n if (present (a)) call abort () end subroutine foo [EMAIL PROTECTED] cpu2006-465e]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/gfortran -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -g -o foo foo.f90 -Wl,-rpath,/usr/gcc-4.2/lib64 [EMAIL PROTECTED] cpu2006-465e]$ ./foo 5 Aborted [EMAIL PROTECTED] cpu2006-465e]$ make zzz /export/build/gnu/gcc/build-x86_64-linux/gcc/gfortran -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -g -o zzz zzz.f90 -Wl,-rpath,/usr/gcc-4.2/lib64 [EMAIL PROTECTED] cpu2006-465e]$ ./zzz Segmentation fault [EMAIL PROTECTED] cpu2006-465e]$ -- Summary: present doesn't work on array Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27035
[Bug fortran/27035] present doesn't work on array
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-04 22:13 --- First off I think the code below is invalid code. I get with Lahey's F95 online compiler: 2602-S: "SOURCE.F90", line 5: The argument number of procedure 'foo' shall be the same between definition and reference. The previous appearance is in 'line 2'. Encountered 1 error, 0 warnings, 0 informations in file SOURCE.F90. Compiling file SOURCE.F90. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27035
[Bug fortran/27035] present doesn't work on array
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-04 22:16 --- With the fixed code: program main call foo (5) contains subroutine foo(n, a) integer :: n integer, dimension(5), optional :: a print *, n if (present (a)) call abort () end subroutine foo end program main It works in 4.1.0 and the mainline so closing as invalid (or this could be closed as a dup of bug 26227 which is the bug records the accepting of the invalid code). -- 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=27035
[Bug fortran/27035] present doesn't work on array
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-04 22:18 --- Lehay's testcase can be found at: http://www.lahey.com/check.htm It is free to use, kinda like Comeau's C/C++ tester. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27035
[Bug fortran/27035] present doesn't work on array
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-04 22:19 --- You can also fix the code by using modules and what is basicially prototypes (I forgot the Fortran name for them). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27035
[Bug other/27029] gcc3.4/make dvi creates .pdf instead of .dvi files
--- Comment #5 from spiralvoice at hotmail dot com 2006-04-04 22:28 --- Yes, 4.0.3 works, did not test any other 4.0.x version -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27029
[Bug preprocessor/27036] New: ICE in dwarf2out_finish, at dwarf2out.c:14116
#v+ $ i586-pc-gnu-gcc -DPACKAGE_NAME=\"GNU\ Hurd\" -DPACKAGE_TARNAME=\"hurd\" -DPACKAGE_VERSION=\"0.3\" -DPACKAGE_STRING=\"GNU\ Hurd\ 0.3\" -DPACKAGE_BUGREPORT=\"[EMAIL PROTECTED]" -DPACKAGE=\"hurd\" -DVERSION=\"0.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_MIG_RETCODE=1 -DHAVE_GETGROUPLIST=1 -DHAVE_USELOCALE=1 -I. -I.. -I. -I. -I.. -Iinclude -I../include -I./include -I. -I. -I.. -Iinclude -I../include -I./include -D_GNU_SOURCE -D_IO_MTSAFE_IO -D_FILE_OFFSET_BITS=64 -O3 -std=gnu99 -g -O2 -MT init/init.o -MD -MP -MF "$depbase.Tpo" -c -o init/init.o ../init/init.c ../init/init.c:53:30: error: startup_notify_U.h: No such file or directory ../init/init.c:54:29: error: startup_reply_U.h: No such file or directory ../init/init.c:55:23: error: startup_S.h: No such file or directory ../init/init.c:56:22: error: notify_S.h: No such file or directory ../init/init.c:57:24: error: mung_msg_S.h: No such file or directory ../init/init.c: In function 'notify_shutdown': ../init/init.c:204: warning: implicit declaration of function 'startup_dosync' ../init/init.c: In function 'launch_core_servers': ../init/init.c:635: warning: implicit declaration of function 'startup_procinit_reply' ../init/init.c:653: warning: implicit declaration of function 'startup_authinit_reply' ../init/init.c: In function 'S_startup_essential_task': ../init/init.c:1203: warning: implicit declaration of function 'startup_essential_task_reply' ../init/init.c: At top level: ../init/init.c:1562: internal compiler error: in dwarf2out_finish, at dwarf2out.c:14116 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. #v- I'm aware that this compilation attempt can't finish successfully, but it shouldn't yield an ICE nevertheless, I think. I was using gcc-4_1-branch from some weeks ago, but just `svn update'd and `make all install'ed to the current one without any other results. #v+ $ i586-pc-gnu-gcc -v -save-temps -DPACKAGE_NAME=\"GNU\ Hurd\" -DPACKAGE_TARNAME=\"hurd\" -DPACKAGE_VERSION=\"0.3\" -DPACKAGE_STRING=\"GNU\ Hurd\ 0.3\" -DPACKAGE_BUGREPORT=\"[EMAIL PROTECTED]" -DPACKAGE=\"hurd\" -DVERSION=\"0.3\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_MIG_RETCODE=1 -DHAVE_GETGROUPLIST=1 -DHAVE_USELOCALE=1 -I. -I.. -I. -I. -I.. -Iinclude -I../include -I./include -I. -I. -I.. -Iinclude -I../include -I./include -D_GNU_SOURCE -D_IO_MTSAFE_IO -D_FILE_OFFSET_BITS=64 -O3 -std=gnu99 -g -O2 -MT init/init.o -MD -MP -MF "$depbase.Tpo" -c -o init/init.o ../init/init.c Using built-in specs. Target: i586-pc-gnu Configured with: /home/thomas/tmp/gnu-2/src/gcc/configure --target=i586-pc-gnu --prefix=/home/thomas/tmp/gnu-2 --with-sysroot=/home/thomas/tmp/gnu-2/sys_root --disable-nls --disable-shared --without-headers --with-newlib --enable-languages=c : (reconfigured) /home/thomas/tmp/gnu-2/src/gcc/configure --target=i586-pc-gnu --prefix=/home/thomas/tmp/gnu-2 --with-sysroot=/home/thomas/tmp/gnu-2/sys_root --disable-nls --enable-languages=c Thread model: single gcc version 4.1.1 20060404 (prerelease) /fs/data/mount/home/thomas/tmp/gnu-2/bin/../libexec/gcc/i586-pc-gnu/4.1.1/cc1 -E -quiet -v -I. -I.. -I. -I. -I.. -Iinclude -I../include -I./include -I. -I. -I.. -Iinclude -I../include -I./include -iprefix /fs/data/mount/home/thomas/tmp/gnu-2/bin/../lib/gcc/i586-pc-gnu/4.1.1/ -isysroot /fs/data/mount/home/thomas/tmp/gnu-2/bin/../sys_root -MD init/init.d -MF .Tpo -MP -MT init/init.o -MQ init/init.o -DPACKAGE_NAME="GNU Hurd" -DPACKAGE_TARNAME="hurd" -DPACKAGE_VERSION="0.3" -DPACKAGE_STRING="GNU Hurd 0.3" -DPACKAGE_BUGREPORT="bug-hurd@gnu.org" -DPACKAGE="hurd" -DVERSION="0.3" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_MIG_RETCODE=1 -DHAVE_GETGROUPLIST=1 -DHAVE_USELOCALE=1 -D_GNU_SOURCE -D_IO_MTSAFE_IO -D_FILE_OFFSET_BITS=64 ../init/init.c -mtune=pentium -std=gnu99 -fworking-directory -O3 -O2 -fpch-preprocess -o init.i ignoring nonexistent directory "/fs/data/mount/home/thomas/tmp/gnu-2/bin/../sys_root/usr/local/include" ignoring duplicate directory "/home/thomas/tmp/gnu-2/lib/gcc/i586-pc-gnu/4.1.1/include" ignoring duplicate directory "/home/thomas/tmp/gnu-2/
[Bug preprocessor/27036] ICE in dwarf2out_finish, at dwarf2out.c:14116
--- Comment #1 from tschwinge at gnu dot org 2006-04-04 22:58 --- Created an attachment (id=11209) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11209&action=view) init.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27036
