The Whore Lived Like a German
Full Article: http://service.spiegel.de/cache/international/0,1518,344374,00.html
[Bug target/21551] [4.0/4.1 Regression] ia64 bootstrap failed
-- What|Removed |Added Summary|[4.0 Regression] ia64 |[4.0/4.1 Regression] ia64 |bootstrap failed|bootstrap failed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21551
Verbrechen der deutschen Frau
Lese selbst: http://www.jn-bw.de/texte/zeitgeschichte/verbrechen_der_frau.htm
[Bug c/21589] New: FAIL: gcc.dg/noreturn-7.c (test for warnings, line 21)
Executing on host: /xxx/gnu/gcc-3.3/objdir/gcc/xgcc -B/xxx/gnu/gcc-3.3/objdir/gc c/ /xxx/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/noreturn-7.c -O2 -Wreturn-type -W missing-noreturn -S -o noreturn-7.s(timeout = 300) /xxx/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/noreturn-7.c: In function `k': /xxx/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/noreturn-7.c:42: warning: control reac hes end of non-void function output is: /xxx/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/noreturn-7.c: In function `k': /xxx/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/noreturn-7.c:42: warning: control reac hes end of non-void function FAIL: gcc.dg/noreturn-7.c (test for warnings, line 21) PASS: gcc.dg/noreturn-7.c (test for bogus messages, line 28) PASS: gcc.dg/noreturn-7.c (test for bogus messages, line 35) PASS: gcc.dg/noreturn-7.c (test for warnings, line 42) PASS: gcc.dg/noreturn-7.c (test for excess errors) This is fixed in 4.0. -- Summary: FAIL: gcc.dg/noreturn-7.c (test for warnings, line 21) Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21589
[Bug c/21590] New: FAIL: gcc.dg/sibcall-1.c and FAIL: gcc.dg/sibcall-2.c
Executing on host: /xxx/gnu/gcc-3.3/objdir/gcc/xgcc -B/xxx/gnu/gcc-3.3/objdir/gc c/ /xxx/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/sibcall-1.c -O2 -foptimize-siblin g-calls -lm -o ./sibcall-1.exe(timeout = 300) PASS: gcc.dg/sibcall-1.c (test for excess errors) Setting LD_LIBRARY_PATH to :/opt/gnu64/gcc/gcc-4.0.0/lib FAIL: gcc.dg/sibcall-1.c execution test Executing on host: /xxx/gnu/gcc-3.3/objdir/gcc/xgcc -B/xxx/gnu/gcc-3.3/objdir/gc c/ /xxx/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/sibcall-2.c -O2 -foptimize-siblin g-calls -lm -o ./sibcall-2.exe(timeout = 300) PASS: gcc.dg/sibcall-2.c (test for excess errors) Setting LD_LIBRARY_PATH to :/opt/gnu64/gcc/gcc-4.0.0/lib FAIL: gcc.dg/sibcall-2.c execution test This bug is fixed in 4.0. These optimizations fail because the argument pointer needs to be copied on this target. -- Summary: FAIL: gcc.dg/sibcall-1.c and FAIL: gcc.dg/sibcall-2.c Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21590
[Bug tree-optimization/21591] New: not vectorizing a loop with access to structs
Take the following C code (reduced from Java code and what the Java front-end
produces).
We cannot vectorize the second loop
struct a
{
int length;
int a1[256];
};
struct a *malloc1(__SIZE_TYPE__) __attribute__((malloc));
void free(void*);
void f(void)
{
struct a *a = malloc1(sizeof(struct a));
struct a *b = malloc1(sizeof(struct a));
struct a *c = malloc1(sizeof(struct a));
int i;
for (i = 0; i < 256; i++) {
b->a1[i] = i;
c->a1[i] = i;
}
for (i = 0; i < 256; i++) {
a->a1[i] = b->a1[i] + c->a1[i];
}
free(a);
free(b);
free(c);
}
Here is what we get from the dump:
t.c:21: note: not vectorized: can't determine dependence between: b_5->a1[i_12]
and a_3->a1[i_12]
--
Summary: not vectorizing a loop with access to structs
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21591
[Bug tree-optimization/21591] not vectorizing a loop with access to structs
-- What|Removed |Added Version|4.0.0 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21591
[Bug tree-optimization/21591] not vectorizing a loop with access to structs
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15
19:03 ---
Note I reduced this from the following Java code:
public class Test {
public static final void main(String[] args) {
int[] a = new int[256];
int[] b = new int[256];
int[] c = new int[256];
for (int i = 0; i < 256; i++) {
b[i] = i;
c[i] = i;
}
for (int i = 0; i < 256; i++) {
a[i] = b[i] + c[i];
}
}
}
But I needed a patch to the java front-end to mark a label decl as
DECL_ARTIFICIAL to get even trying to
vectorize the loop (and -fno-bounds-check).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21591
[Bug c/21589] [3.4 only] FAIL: gcc.dg/noreturn-7.c (test for warnings, line 21)
-- What|Removed |Added Summary|FAIL: gcc.dg/noreturn-7.c |[3.4 only] FAIL: |(test for warnings, line 21)|gcc.dg/noreturn-7.c (test ||for warnings, line 21) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21589
[Bug target/21590] [3.4 only] FAIL: gcc.dg/sibcall-1.c and FAIL: gcc.dg/sibcall-2.c
-- What|Removed |Added Component|c |target Keywords||missed-optimization Summary|FAIL: gcc.dg/sibcall-1.c and|[3.4 only] FAIL: |FAIL: gcc.dg/sibcall-2.c|gcc.dg/sibcall-1.c and FAIL: ||gcc.dg/sibcall-2.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21590
[Bug java/21519] ICE in generate_bytecode_conditional, at java/jcf-write.c:1337
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-15 19:09 --- Subject: Bug 21519 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-15 19:09:30 Modified files: gcc/java : ChangeLog jcf-write.c libjava: ChangeLog Added files: libjava/testsuite/libjava.compile: pr21519.java pr21519.no-link Log message: gcc/java: PR java/21519: * jcf-write.c (generate_bytecode_insns) : Don't call NOTE_PUSH. libjava: PR java/21519: * testsuite/libjava.compile/pr21519.java: New file. * testsuite/libjava.compile/pr21519.no-link: New file. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1556.2.20&r2=1.1556.2.21 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/jcf-write.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.162&r2=1.162.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.65&r2=1.3391.2.66 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.compile/pr21519.java.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.compile/pr21519.no-link.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21519
Dresden 1945
Lese selbst: http://www.kommunisten-online.de/blackchanel/dresden3.htm
Transparenz ist das Mindeste
Lese selbst: http://www.npd.de/npd_info/deutschland/2005/d0405-39.html
Dresden Bombing Is To Be Regretted Enormously
Full Article: http://service.spiegel.de/cache/international/0,1518,341239,00.html
[Bug java/21519] ICE in generate_bytecode_conditional, at java/jcf-write.c:1337
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-15 19:13 --- Fix checked in. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21519
[Bug middle-end/21538] g++.dg/opt/temp1.C should be optimized elsewhere
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-15 19:30 --- This optimization should take place in cp/typeck:build_indirect_ref where it even tries to do so but fails because it does not strip NOP_EXPRs before checking for the optimization and also because same_types_p says const T and T are not equal. Where we have a MODIFY_EXPR(T, const T) and the const T coming from argument conversion to operator=(const T&). Maybe carrying out the actual conversion for creating of the MODIFY_EXPR is not necessary. In build_indirect_ref we end up with sth like (struct TD.1679 &) (struct TD.1679 *) &TARGET_EXPR when the only thing we are doing is a conversion from T& to const T&. Deferred to someone knowing the C++ frontend - this optimization certainly should take place there. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[4.0/4.1 Regression]|g++.dg/opt/temp1.C should be |g++.dg/opt/temp1.C execution|optimized elsewhere |test fails | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21538
Auslaender bevorzugt
Lese selbst: http://www.npd.de/npd_info/deutschland/2005/d0305-14.html Jetzt weiss man auch, wie es dazu kommt, dass Drogen, Waffen & Handy's in die Haende der Knacki's gelangen!
Massenhafter Steuerbetrug durch auslaendische Arbeitnehmer
Lese selbst: http://www.rp-online.de/public/article/nachrichten/wirtschaft/finanzen/deutschland/85815
The Whore Lived Like a German
Full Article: http://service.spiegel.de/cache/international/0,1518,344374,00.html
[Bug libfortran/20930] [4.0 Regression] gfortran.dg/backspace.f execution test
--- Additional Comments From dje at gcc dot gnu dot org 2005-05-15 19:54 --- This bug has not been fixed on the 4.0 branch -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20930
S.O.S. Kiez! Polizei schlaegt Alarm
Lese selbst: http://bz.berlin1.de/archiv/041115_pdf/BZ041115_004_GB2IG556.1.htm
[Bug c++/21583] FAIL: g++.old-deja/g++.eh/badalloc1.C execution test
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-15 20:08 --- Present on sparc-sun-solaris2.10 too, only on 3.4 branch. Same symptom: not enough space to allocate an exception so an exception is raised. :-) -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-15 20:08:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21583
Graeberschaendung auf bundesdeutsche Anordnung
Lese selbst: http://www.die-kommenden.net/dk/zeitgeschichte/graeberschaendung.htm
[Bug c++/21592] New: ICE
-- Summary: ICE Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21592
[Bug c++/21592] ICE
--- Additional Comments From igodard at pacbell dot net 2005-05-15 20:18 --- Created an attachment (id=8893) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8893&action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21592
[Bug c++/21592] ICE
--- Additional Comments From igodard at pacbell dot net 2005-05-15 20:18 --- Created an attachment (id=8894) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8894&action=view) source code (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21592
[Bug c++/21583] FAIL: g++.old-deja/g++.eh/badalloc1.C execution test
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-05-15 20:42 --- Subject: Re: FAIL: g++.old-deja/g++.eh/badalloc1.C execution test > The arena_size size change by itself is not sufficient. However, > backporting the 4.0 changes fixes the fail. I just realized that the 4.0 version doesn't have Joseph's change for ia64 hpux. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21583
[Bug c++/21592] [3.4/4.0/4.1 Regression] ICE in resolve_overloaded_unification
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15
20:57 ---
Confirmed, reduced testcase:
class cl
{
int str();
void str(const int& __s);
};
template
int &f(const T& t);
template
void g()
{
cl str;
f(str.str);
}
---
I don't know if this is valid code or not, 3.3.3 accepted it and so does ICC
even in strict mode.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Known to fail||3.4.0 4.0.0 4.1.0
Known to work||3.3.3
Last reconfirmed|-00-00 00:00:00 |2005-05-15 20:57:07
date||
Summary|ICE |[3.4/4.0/4.1 Regression] ICE
||in
||resolve_overloaded_unificati
||on
Target Milestone|--- |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21592
[Bug c++/21509] [3.4/4.0 regression] -Wformat=2 incorrectly warns about string literalness
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-15 20:59 --- Fixed on mainline. -- What|Removed |Added Known to fail|3.4.0 4.0.0 4.1.0 |3.4.0 4.0.0 Known to work|3.3.3 |3.3.3 4.1.0 Summary|[3.4/4.0/4.1 regression] - |[3.4/4.0 regression] - |Wformat=2 incorrectly warns |Wformat=2 incorrectly warns |about string literalness|about string literalness http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21509
[Bug c++/21592] [3.4/4.0/4.1 Regression] ICE in resolve_overloaded_unification/arg_assoc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 21:02 --- Note the ICE moved from arg_assoc to resolve_overloaded_unification in 4.0.0. -- What|Removed |Added Summary|[3.4/4.0/4.1 Regression] ICE|[3.4/4.0/4.1 Regression] ICE |in |in |resolve_overloaded_unificati|resolve_overloaded_unificati |on |on/arg_assoc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21592
[Bug fortran/21593] New: FAIL: gfortran.dg/dev_null.f90
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/../gfortran -B/mnt/gnu/ gcc-3.3/objdir/gcc/testsuite/../ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gfortran.dg/ dev_null.f90 -O0 -pedantic-errors -L/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpu x11.11/./libgfortran/.libs -L/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./lib iberty -lm -o ./dev_null.exe(timeout = 300) PASS: gfortran.dg/dev_null.f90 -O0 (test for excess errors) Setting LD_LIBRARY_PATH to .:/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./lib gfortran/.libs:/mnt/gnu/gcc-3.3/objdir/gcc:.:/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp -hpux11.11/./libgfortran/.libs:/mnt/gnu/gcc-3.3/objdir/gcc FAIL: gfortran.dg/dev_null.f90 -O0 execution test Test fails at all optimizations. -- Summary: FAIL: gfortran.dg/dev_null.f90 Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21593
Schily ueber Deutschland
Lese selbst: http://www.heise.de/newsticker/meldung/59427
[Bug fortran/21594] New: FAIL: gfortran.dg/eoshift.f90 -O0 execution test
Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/testsuite/../gfortran -B/mnt/gnu/ gcc-3.3/objdir/gcc/testsuite/../ /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gfortran.dg/ eoshift.f90 -O0 -pedantic-errors -L/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux 11.11/./libgfortran/.libs -L/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./libi berty -lm -o ./eoshift.exe(timeout = 300) PASS: gfortran.dg/eoshift.f90 -O0 (test for excess errors) Setting LD_LIBRARY_PATH to .:/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/./lib gfortran/.libs:/mnt/gnu/gcc-3.3/objdir/gcc:.:/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp -hpux11.11/./libgfortran/.libs:/mnt/gnu/gcc-3.3/objdir/gcc FAIL: gfortran.dg/eoshift.f90 -O0 execution test Test only fails at -O0. -- Summary: FAIL: gfortran.dg/eoshift.f90 -O0 execution test Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21594
[Bug middle-end/21595] New: __builtin_constant_p(&"Hello"[0]) is true for C but not for C++
... because of different representations are passed to fold_builtin_constant_p. -- Summary: __builtin_constant_p(&"Hello"[0]) is true for C but not for C++ Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21595
[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)
--- Additional Comments From aj at gcc dot gnu dot org 2005-05-15 21:37 --- Paul, could you review the patch, please? -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pbrook at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080
[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-05-15 21:42 --- I already did. http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01246.html -- What|Removed |Added AssignedTo|pbrook at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080
[Bug middle-end/21595] __builtin_constant_p(&"Hello"[0]) is true for C but not for C++
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-15 21:47 --- patch in testing -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-15 21:47:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21595
Verbrechen der deutschen Frau
Lese selbst: http://www.jn-bw.de/texte/zeitgeschichte/verbrechen_der_frau.htm
The Whore Lived Like a German
Full Article: http://service.spiegel.de/cache/international/0,1518,344374,00.html
[Bug middle-end/21460] Internal compiler error in calc_dfs_tree on valid code
-- What|Removed |Added CC||ssolie at telus dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21460
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From schlie at comcast dot net 2005-05-15 22:45 --- (In reply to comment #2) > Yup, string literal should have type 'const char *'. I believe 'static const char []' would seem most correct? (where although 'static const' may be cast away, there's no guarantee that any attempted write will not only potentially fail, but may generate terminal exception if the string literal is stored in physically write protected memory or physically in ROM) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From schlie at comcast dot net 2005-05-15 22:50 --- (In reply to comment #1) > With -Wwrite-strings, I do get a warning: > t.cc:3: warning: deprecated conversion from string constant to �char*�' - arguably, this warning should always be on, and only optionally turned off when one want's to live dangeriously; it would seem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
Armenian Genocide Plagues Ankara 90 Years On
Full Article: http://service.spiegel.de/cache/international/0,1518,353274,00.html
[Bug tree-optimization/21596] New: [4.0/4.1 Regression] extra temporaries when using global register variables
register int *reg __asm__("%edi");
int test () { return *--reg <= 0; }
With -O2 -fomit-frame-pointer, 4.0,
movl%edi, %eax
leal-4(%edi), %edi
movl-4(%eax), %eax
testl %eax, %eax
With 3.4,
subl$4, %edi
cmpl$0, (%edi)
The problem appears to begin at the tree level, with extra temporaries:
reg.0 = reg;
reg.2 = reg.0 - 4B;
reg = reg.2;
return *reg.2 <= 0;
We do consider hard register variables not is_gimple_reg, due to needing
to V_MAY_DEF them at call sites. It would be nice if we could eliminate
these temporaries during TER, or something.
--
Summary: [4.0/4.1 Regression] extra temporaries when using global
register variables
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rth at gcc dot gnu dot org
CC: amacleod at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21596
[Bug tree-optimization/21596] [4.0/4.1 Regression] extra temporaries when using global register variables
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-15 23:57 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-05-15 23:57:38 date|| Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21596
[Bug middle-end/21595] [4.0/4.1 Regression] __builtin_constant_p(&"Hello"[0]) is true for C but not for C++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16 00:02 --- This is also a regression from 3.4.0. -- What|Removed |Added Keywords||missed-optimization Known to fail||4.0.0 4.1.0 Known to work||3.4.0 Summary|__builtin_constant_p(&"Hello|[4.0/4.1 Regression] |"[0]) is true for C but not |__builtin_constant_p(&"Hello |for C++ |"[0]) is true for C but not ||for C++ Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21595
[Bug middle-end/21595] [4.0/4.1 Regression] __builtin_constant_p(&"Hello"[0]) is true for C but not for C++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16 00:04 --- Here is a compile time testcase: int f[__builtin_constant_p(&"Hello"[0])?1:-1]; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21595
[Bug tree-optimization/21559] [4.1 Regression] missed jump threading
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-16 00:07:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21559
[Bug target/21597] New: libgcc broken on targets with MKDIR_TAKES_ONE_ARG
This change: 2005-05-10 Grigory Zagorodnev <[EMAIL PROTECTED]> H.J. Lu <[EMAIL PROTECTED]> * libgcov.c (create_file_directory): New function. Create directory for the given file name. breaks build on mingw32 with: ../../gcc/gcc/libgcov.c: In function 'create_file_directory': ../../gcc/gcc/libgcov.c:115: error: too many arguments to function 'mkdir' make[2]: *** [libgcc/./_gcov.o] Error 1 make[1]: *** [libgcc.a] Error 2 make: *** [all-gcc] Error 2 -- Summary: libgcc broken on targets with MKDIR_TAKES_ONE_ARG Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dannysmith at users dot sourceforge dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21597
[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-16
00:10 ---
this fails for me with -O in CCP. In .t18.copyrename1 we have:
;; Function void f(FILE*) (_Z1fP6__FILE)
Partition map
void f(FILE*) (fileD.2015)
Eh tree:
1 allowed_exceptions tree_label:
{
const charD.3 * strD.2018;
# BLOCK 0
# PRED: ENTRY (fallthru)
strD.2018_1 = &"a"[0];
# TMT.1D.2025_4 = V_MAY_DEF ;
fputs (strD.2018_1, fileD.2015_2);
goto ();
# SUCC: 1 (ab,eh) 2 (fallthru)
# BLOCK 1
# PRED: 0 (ab,eh)
:;
# VUSE ;
__cxa_call_unexpected (<<>>);
# SUCC:
# BLOCK 2
# PRED: 0 (fallthru)
:;
return;
# SUCC: EXIT
}
In .t18.ccp, we have the following replacement:
Replaced fputs (str_1, file_2);
with __builtin_fputc (97, file_2);
which is probably to blame for this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399
[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-16
00:13 ---
At the point of the ICE, I have this (from gdb's "p dump_tree_cfg(0)"):
void f(FILE*) (fileD.2015)
{
const char * str;
# BLOCK 0
# PRED: ENTRY (fallthru,exec)
str_1 = &"a"[0];
__builtin_fputc (97, file_2);
goto ();
# SUCC: 1 (ab,eh,exec) 2 (fallthru,exec)
# BLOCK 1
# PRED: 0 (ab,eh,exec)
:;
__cxa_call_unexpected (<<>>);
# SUCC:
# BLOCK 2
# PRED: 0 (fallthru,exec)
:;
return;
# SUCC: EXIT
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399
[Bug middle-end/21597] [4.1 Regression] libgcc broken on targets with MKDIR_TAKES_ONE_ARG
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16 00:13 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|target |middle-end Ever Confirmed||1 Keywords||build Last reconfirmed|-00-00 00:00:00 |2005-05-16 00:13:54 date|| Summary|libgcc broken on targets|[4.1 Regression] libgcc |with MKDIR_TAKES_ONE_ARG|broken on targets with ||MKDIR_TAKES_ONE_ARG Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21597
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From gdr at integrable-solutions dot net 2005-05-16 00:14 --- Subject: Re: static_cast falsely allows const to be cast away "schlie at comcast dot net" <[EMAIL PROTECTED]> writes: | --- Additional Comments From schlie at comcast dot net 2005-05-15 22:45 --- | (In reply to comment #2) | > Yup, string literal should have type 'const char *'. | | I believe 'static const char []' would seem most correct? "static" is not part of the type. The ty[e of a string literal is "const char[N]", N being its sizeof. There is no if no but. Similar rule for wide string literal. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-16 00:16 --- For CCP there is code to remove EH edges in tree-ssa-propagate.c, but it does not trigger: Breakpoint 3, substitute_and_fold (prop_value=0xf3e3a0) at tree-ssa-propagate.c:1063 1063 if (maybe_clean_eh_stmt (stmt)) (gdb) p debug_generic_stmt(stmt) # TMT.1D.2025_4 = V_MAY_DEF ; __builtin_fputc (97, fileD.2015_2); $2 = void (gdb) p maybe_clean_eh_stmt (stmt) $3 = 0 '\0' (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399
[Bug middle-end/21538] g++.dg/opt/temp1.C should be optimized elsewhere
--- Additional Comments From mark at codesourcery dot com 2005-05-16 00:17 --- Subject: Re: g++.dg/opt/temp1.C should be optimized elsewhere rguenth at gcc dot gnu dot org wrote: > --- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-15 > 19:30 --- > This optimization should take place in > > cp/typeck:build_indirect_ref > > where it even tries to do so but fails because it does not strip > NOP_EXPRs before checking for the optimization and also because > same_types_p says const T and T are not equal. They're not equal, and I don't think this should be fixed in build_indirect_ref. It definitely seems like something that should be optimized in the middle end. In any case, given that you've kindly reverted your patch, is there any reason that the 4.0.1 target milestone is still on this PR, or may I remove it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21538
[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-16
00:26 ---
We have this code in tree-ssa-propagate.c:1052-1065:
if (did_replace)
{
fold_stmt (bsi_stmt_ptr (i));
stmt = bsi_stmt(i);
/* If we folded a builtin function, we'll likely
need to rename VDEFs. */
mark_new_vars_to_rename (stmt);
/* If we cleaned up EH information from the statement,
remove EH edges. */
if (maybe_clean_eh_stmt (stmt))
tree_purge_dead_eh_edges (bb);
}
But maybe_clean_eh_stmt returns false. Why??
Because we replace the entire statement apparently. So we get to tree-eh.c:
Breakpoint 4, substitute_and_fold (prop_value=0xf3e3a0) at
tree-ssa-propagate.c:1054
1054 fold_stmt (bsi_stmt_ptr (i));
(gdb) p *bsi_stmt_ptr(i)
$12 = 0x2a95896550
(gdb) p debug_generic_stmt (*bsi_stmt_ptr(i))
# TMT.1D.2025_4 = V_MAY_DEF ;
fputs (&"a"[0], fileD.2015_2);
$13 = void
(gdb) cont
Continuing.
Breakpoint 3, substitute_and_fold (prop_value=0xf3e3a0) at
tree-ssa-propagate.c:1063
1063 if (maybe_clean_eh_stmt (stmt))
(gdb) p stmt
$14 = 0x2a95896d70
1063 if (maybe_clean_eh_stmt (stmt))
(gdb) p debug_generic_stmt(stmt)
# TMT.1D.2025_4 = V_MAY_DEF ;
__builtin_fputc (97, fileD.2015_2);
$8 = void
(gdb) step
maybe_clean_eh_stmt (stmt=0x2a95896d70) at tree-eh.c:2040
2040 if (!tree_could_throw_p (stmt))
(gdb) next
2041if (remove_stmt_from_eh_region (stmt))
(gdb)
2043 return false;
(gdb)
So we try to remove the _new_ statement from the EH region, and leave the
old one right there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399
[Bug middle-end/21331] [4.0 Regression] Incorrect folding of comparison
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16 00:28 --- Mine, patch posted. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||05/msg01485.html Status|NEW |ASSIGNED Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21331
[Bug tree-optimization/21293] [4.0 Regression] ICE in set_value_handle
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16 00:29 --- Mine, patch posted. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||05/msg01485.html Status|NEW |ASSIGNED Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21293
Du wirst ausspioniert ....!
und weisst es nicht einmal: http://www.heise.de/newsticker/meldung/58003 http://www.heise.de/newsticker/meldung/59304 http://www.heise.de/newsticker/meldung/58311 http://www.heise.de/newsticker/meldung/58351
[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-16
00:40 ---
The same problem is in tree-ssa-dom.c:2975:
/* Try to fold the statement making sure that STMT is kept
up to date. */
if (fold_stmt (bsi_stmt_ptr (si)))
{
stmt = bsi_stmt (si);
Later on it calls maybe_clean_eh_stmt on the new stmt.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399
[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE
--- Additional Comments From steven at gcc dot gnu dot org 2005-05-16
00:42 ---
We probably need something like,
bool
maybe_clean_eh_after_replacing_stmt (tree old_stmt, tree new_stmt)
{
if (!tree_could_throw_p (new_stmt))
if (remove_stmt_from_eh_region (old_stmt))
return true;
return false;
}
and use it in the two places I pointed out. I think the others are safe.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399
[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16
00:44 ---
This patch works for me on this testcase, I have not done a full bootstrap/test
yet:
Index: tree-ssa-propagate.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-propagate.c,v
retrieving revision 2.19
diff -u -p -r2.19 tree-ssa-propagate.c
--- tree-ssa-propagate.c11 May 2005 08:14:24 - 2.19
+++ tree-ssa-propagate.c16 May 2005 00:43:18 -
@@ -558,7 +558,7 @@ get_rhs (tree stmt)
bool
set_rhs (tree *stmt_p, tree expr)
{
- tree stmt = *stmt_p, op;
+ tree stmt = *stmt_p, op, new_stmt;
enum tree_code code = TREE_CODE (expr);
stmt_ann_t ann;
tree var;
@@ -621,7 +621,17 @@ set_rhs (tree *stmt_p, tree expr)
/* Replace the whole statement with EXPR. If EXPR has no side
effects, then replace *STMT_P with an empty statement. */
ann = stmt_ann (stmt);
- *stmt_p = TREE_SIDE_EFFECTS (expr) ? expr : build_empty_stmt ();
+ new_stmt = TREE_SIDE_EFFECTS (expr) ? expr : build_empty_stmt ();
+ {
+/* Update the eh region for the new statement. */
+int old_eh_region = lookup_stmt_eh_region (stmt);
+ if (old_eh_region >= 0)
+ {
+ remove_stmt_from_eh_region (stmt);
+ add_stmt_to_eh_region (new_stmt, old_eh_region);
+ }
+ }
+ *stmt_p = new_stmt;
(*stmt_p)->common.ann = (tree_ann_t) ann;
if (TREE_SIDE_EFFECTS (expr))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16 00:51 --- Subject: Bug 21526 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-16 00:51:42 Modified files: gcc/testsuite/lib: target-supports.exp gcc/testsuite : ChangeLog Log message: 2005-05-16 David Billinghurst <[EMAIL PROTECTED]> PR libstdc++/21526 * lib/target-supports.exp (check_mkfifo_available): Return 0 for cygwin as mkfifo support incomplete on platform. Fix typos in comments. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/lib/target-supports.exp.diff?cvsroot=gcc&r1=1.56&r2=1.57 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5475&r2=1.5476 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16 00:55 --- Subject: Bug 21526 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-16 00:55:29 Modified files: gcc/testsuite/lib: target-supports.exp gcc/testsuite : ChangeLog Log message: 2005-05-16 David Billinghurst <[EMAIL PROTECTED]> PR libstdc++/21526 * lib/target-supports.exp (check_mkfifo_available): Return 0 for cygwin as mkfifo support incomplete on platform. Fix typos in comments. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/lib/target-supports.exp.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.40.4.4&r2=1.40.4.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.178&r2=1.5084.2.179 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
Du wirst ausspioniert ....!
und weisst es nicht einmal: http://www.heise.de/newsticker/meldung/58003 http://www.heise.de/newsticker/meldung/59304 http://www.heise.de/newsticker/meldung/58311 http://www.heise.de/newsticker/meldung/58351
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From billingd at gcc dot gnu dot org 2005-05-16 00:58 --- Fixed by patch to lib/target-supports.exp. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
[Bug libstdc++/21526] libstdc++-v3 testsuite hangs on cygwin
--- Additional Comments From david dot billinghurst at comalco dot riotinto
dot com dot au 2005-05-16 00:59 ---
Subject: Testsuite patch committed
This fix that Mark Mitchell suggested has been tested on cywin and irix.
Committed to 4.0 and HEAD.
2005-05-16 David Billinghurst <[EMAIL PROTECTED]>
PR libstdc++/21526
* lib/target-supports.exp (check_mkfifo_available):
Return 0 for cygwin as mkfifo support incomplete on platform.
Fix typos in comments.
diff -u -r1.56 target-supports.exp
--- lib/target-supports.exp 6 May 2005 17:03:10 - 1.56
+++ lib/target-supports.exp 16 May 2005 00:41:59 -
@@ -636,15 +636,20 @@
eval return \$$var
}
-# Returns ture iff "fork" is available on the target system.
+# Returns true iff "fork" is available on the target system.
proc check_fork_available {} {
return [check_function_available "fork"]
}
-# Returns ture iff "mkfifo" is available on the target system.
+# Returns true iff "mkfifo" is available on the target system.
proc check_mkfifo_available {} {
+if {[istarget *-*-cygwin*]} {
+ # Cygwin has mkfifo, but support is incomplete.
+ return 0
+ }
+
return [check_function_available "mkfifo"]
}
NOTICE
This e-mail and any attachments are private and confidential and may contain
privileged information. If you are not an authorised recipient, the copying or
distribution of this e-mail and any attachments is prohibited and you must not
read, print or act in reliance on this e-mail or attachments.
This notice should not be removed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21526
[Bug tree-optimization/21576] FRE does not eliminate a redundant builtin call.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16 01:13 --- Subject: Bug 21576 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-16 01:12:09 Modified files: gcc: ChangeLog tree-ssa-pre.c tree-vn.c gcc/testsuite/gcc.dg/tree-ssa: ssa-dom-cse-1.c Added files: gcc/testsuite/gcc.dg/tree-ssa: ssa-pre-10.c ssa-pre-11.c ssa-pre-12.c ssa-pre-13.c ssa-pre-9.c Log message: 2005-05-15 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/21576 * tree-ssa-pre.c (expression_node_pool): New pool. (comparison_node_pool): Ditto. (list_node_pool): Ditto. (pool_copy_list): New function. (phi_translate): Handle CALL_EXPR. (valid_in_set): Ditto. (create_expression_by_pieces): Ditto. (insert_into_preds_of_block): Ditto. (insert_aux): Ditto. (compute_avail): Ditto. (create_value_expr_from): Handle TREE_LIST and CALL_EXPR. (can_value_number_call): New function. (find_leader): Update comment. (init_pre): Create new pools. (fini_pre): Free new pools. (pass_pre): Add TODO_update_ssa for the future when we are going to need vops. * tree-vn.c (expressions_equal_p): Handle TREE_LIST. (set_value_handle): Ditto. (get_value_handle): Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8792&r2=2.8793 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-pre.c.diff?cvsroot=gcc&r1=2.86&r2=2.87 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vn.c.diff?cvsroot=gcc&r1=2.10&r2=2.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-10.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-11.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-12.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-13.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-9.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-cse-1.c.diff?cvsroot=gcc&r1=1.4&r2=1.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21576
[Bug tree-optimization/21576] FRE does not eliminate a redundant builtin call.
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-05-16 01:14 --- I fixed it, and made it PRE calls too -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21576
The world is really unstable these days......
We've got a lot to deal with these days. Terrorism, Recession, Weather and more. It's all got me concerned. I thought I'd tell you all about this group I found where everyday people get together and try to learn how to deal with it all. (I used to be a member, but I'm moving to an area that doesn't have internet, so I left a few days ago. Internet is off tomorrow) Here's a bit on the group. Check it out or don't. misc_survivalism_moderated · Survivalism and Preparedness. http://groups.yahoo.com/group/misc_survivalism_moderated This list is for those who want themselves and their loved ones to survive and prosper during hard times. War, riots, famine, crime, drought, flooding, fire, contaminated water supplies, inflation, job loss, and many more. Are you ready to deal with any situation? Join us as we learn from each other how to survive. On-topic: Food storage, firearms, canning, gardening, self-sustaining communities, back to basics, water purification, alternative power, conservation, homesteading, first aid and more. Off-topic: Politics, religion, current affairs, philosophy, conspiracy theories, New World Order, racism. --- Nowadays, it improves a tree too blank for her sour mountain. I was irrigating books to easy Diane, who's helping behind the desk's monolith. Guglielmo, have a filthy teacher. You won't shout it. You won't hate me moving near your handsome bedroom. Never play regularly while you're killing with a cosmetic jug. Sometimes, Katherine never fills until Aziz sows the younger frame neatly. One more quiet tickets open Hassan, and they locally care Anastasia too. He should pull once, learn firmly, then look for the cat over the hair. She wants to dream bizarre printers outside Mohammar's ladder. When does Haji pour so finitely, whenever Russ creeps the smart carrot very sneakily? Get your crudely recommending egg inside my mirror. Chester's frog dines near our grocer after we attempt on it. A lot of kind long units will biweekly mould the farmers. Saad, still calling, expects almost furiously, as the butcher seeks outside their cobbler. It can quietly converse strange and lives our noisy, blunt exits throughout a hill. While pools happily recollect bandages, the shopkeepers often jump for the inner shoes.
[Bug AWT/21598] New: rendering problem with button text
I'm using the applet here: http://www.chessgames.com/perl/chessgame?gid=1069669 with gcjappletviewer. (As of this writing I needed a patch to make this work at all, see the classpath-patches list.) In this applet, there are some buttons whose text is cut in half. This happens for all the buttons with text on them. -- Summary: rendering problem with button text Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: tromey at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21598
[Bug AWT/21599] New: transparent images don't work
I'm using the applet here: http://www.chessgames.com/perl/chessgame?gid=1069669 with gcjappletviewer. (As of this writing I needed a patch to make this work at all, see the classpath-patches list.) If I run this applet with the JDK, the images for the chess pieces appear to have a transparent background. With gcjappletviewer, they do not, which looks noticeably odd. -- Summary: transparent images don't work Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: tromey at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21599
[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16 01:23 --- Neither patches are fully complete and here is why, even though fold creates a new CALL_EXPR, we still need to copy the eh_region the function can throw so Steven's patch is not complete, we don't check for this right now but it is hard to test for (maybe). Second if we have a throw to a throw to a non throw function, we need to clean up the regions, so my patch in comment #12 is not complete. I have a fix which I am writting up right now which combines the two problems, we have to change the interface for set_rhs and fold_stmt so they return if you need to removal of eh edges. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399
[Bug tree-optimization/21576] FRE does not eliminate a redundant builtin call.
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21576
[Bug AWT/21600] New: race condition with java applet
I'm using the applet here: http://www.chessgames.com/perl/chessgame?gid=1069669 with gcjappletviewer. (As of this writing I needed a patch to make this work at all, see the classpath-patches list.) Sometimes running this applet works fine. Other times, the window appears but it is very small. When I resize it, I see that the buttons are there, but the rest of the contents (the chess board) are not. It seems to start more reliably when I run gcjappletviewer in the debugger. -- Summary: race condition with java applet Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: tromey at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21600
[Bug c++/21601] New: Friend of template argument constructor
If we try and make \class{A} inherit from \class{B} which is
friends with A's constructor, the compiler segfaults.
template
class B
{
public:
friend T::T(B&);
// void some()
// {
// T t = T::T(*this);
// }
};
class A : public B
{
public:
A(B& b);
};
A::A(B& b)
:B(b)
{
}
--
Summary: Friend of template argument constructor
Product: gcc
Version: 3.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: charles dot gretton at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21601
[Bug c++/21601] Friend of template argument constructor
--- Additional Comments From charles dot gretton at gmail dot com 2005-05-16 01:37 --- Should report: src_file_name:9: error: template parameters cannot be friends -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21601
[Bug middle-end/20218] Can't use __attribute__ ((visibility ("hidden"))) to hide a symbol
--- Additional Comments From pluto at agmk dot net 2005-05-16 01:42 --- (In reply to comment #16) > I posted an updated patch > > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00391.html > > It works for me on ia32, ia64 and x86_64. with this version of the patch gcc builds fine on x86_64. PR20218 testcase works, PR21382 testcase still fails. # gcc-4.0.1-20050514 + patches for PR19664,PR20218. (...) .libs/IexBaseExc.o: In function `Iex::BaseExc::~BaseExc()': IexBaseExc.cpp:(.text+0x59): undefined reference to `std::basic_string, std::allocator >::~basic_string()' /usr/bin/ld: .libs/IexBaseExc.o: relocation R_X86_64_PC32 against `_ZNSsD1Ev' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status (...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug c++/21592] [3.4/4.0/4.1 Regression] ICE in resolve_overloaded_unification/arg_assoc
--- Additional Comments From giovannibajo at libero dot it 2005-05-16 01:43 --- Definitely invalid code, you can't do anything with a bound pointer in C++. Comeau strict mode reports the error: "ComeauTest.c", line 14: error: a pointer to a bound function may only be used to call the function Wild Guess: You're calling a member function and forgot the ()'s f(str.str); ^ -- What|Removed |Added Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21592
[Bug middle-end/21602] New: builtin memmove could be memcpy is src and dst don't alias
The current builtin memmove optimizes to memcpy if it can prove that the source
pointer is in readonly memory, under the assumption that the destination
pointer must be writable and therefore couldn't overlap. However we could
generalize this such that if we can prove the source and dest don't alias, then
we can do the transformation. E.g. given the following code, we should
optimize the memmove call in both foo() and bar(), however we only do foo() in
mainline.
typedef __SIZE_TYPE__ size_t;
extern void *malloc (size_t);
extern void *memmove (void *, const void *, size_t);
void *foo (void)
{
void *dst = malloc (13);
return memmove (dst, "hello world\n", 13);
}
void *bar (void *src)
{
void *dst = malloc(13);
return memmove (dst, src, 13);
}
--
Summary: builtin memmove could be memcpy is src and dst don't
alias
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21602
[Bug target/21551] [4.0/4.1 Regression] ia64 bootstrap failed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16 02:12 --- Subject: Bug 21551 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-16 02:12:03 Modified files: gcc: ChangeLog gcc/config/ia64: ia64.c Log message: 2005-05-15 H.J. Lu <[EMAIL PROTECTED]> PR target/21551 * config/ia64/ia64.c (ia64_expand_move): Don't add addend twice. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8793&r2=2.8794 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&r1=1.363&r2=1.364 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21551
[Bug target/21551] [4.0/4.1 Regression] ia64 bootstrap failed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16 02:14 --- Subject: Bug 21551 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-16 02:14:08 Modified files: gcc: ChangeLog gcc/config/ia64: ia64.c Log message: 2005-05-15 H.J. Lu <[EMAIL PROTECTED]> PR target/21551 * config/ia64/ia64.c (ia64_expand_move): Don't add addend twice. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.245&r2=2.7592.2.246 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.347.2.5&r2=1.347.2.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21551
[Bug c++/21603] New: C++ front-end accepts "new" with VLAs
All three lines marked with comments in:
void f(int n) {
typedef int T[n][n];
new int[n][n]; // #1
new (int[n][n]); // #2
new T; // #3
}
are invalid, but only the first receives an error without -pedantic.
That's an inconsistency; either we should allow all, or none, of the
declarations. Which should it be?
Steve Adamczyk has indicated that he feels that permitting dynamic allocation of
VLAs is a mistake, in that, for example, you can't easily use the pointer
outside the scope of the containing function, unless you somehow also pass/save
the bounds.
--
Summary: C++ front-end accepts "new" with VLAs
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mmitchel at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,jason at redhat dot
com,nathan at codesourcery dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21603
[Bug middle-end/21602] builtin memmove could be memcpy is src and dst don't alias
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16 02:19 --- Confirmed. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-16 02:19:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21602
[Bug target/21551] [4.0/4.1 Regression] ia64 bootstrap failed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16 02:22 --- Fixed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21551
[Bug fortran/17142] assertion "POINTER_TYPE_P (TREE_TYPE (se->expr))" failed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16 02:28 --- This is fixed, this is a dup of bug 17423. *** This bug has been marked as a duplicate of 17423 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17142
[Bug fortran/17423] gfortran segfault when compiling FM509.f from NIST testsuite
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-16 02:29 --- *** Bug 17142 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||epc8 at juno dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17423
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From schlie at comcast dot net 2005-05-16 02:44 --- (In reply to comment #5) > Subject: Re: static_cast falsely allows const to be cast away > | > Yup, string literal should have type 'const char *'. > | > | I believe 'static const char []' would seem most correct? > > "static" is not part of the type. The ty[e of a string literal is > "const char[N]", N being its sizeof. There is no if no but. > Similar rule for wide string literal. Then maybe GCC needs to broaden it's view of what information needs to be considered a type qualifier at least internally; as a storage specification can certainly restrict an object's permissible use and access, as such should be recorded and maintained as a qualifier for all objects, and pointers/references. A literal string is not simply a 'const char [N]' object, as a literal value may not be specified as a target of an assignment, directly or indirectly though a pointer cast to a non-const object reference, unlike as a plain old 'const' objects may be. Therefore possibly GCC needs to internally (and possibly optionally externally) introduce a 'literal' type qualifier, which is stronger than 'const', which may not be cast away, or be disregarded when a so qualified pointer is passed as an argument to, or returned from a function call. As although C/C++ languages don't define a 'literal' type/storage qualifier 'key-word', they certainly do specify restricted semantics for literal data use/access. Which today GCC tries to deal with by wrapping in constructors, and/or attempting to use some un-coordinated combination of 'const" and/or TREE_READONLY object or reference attributes; where a 'literal' type qualifier would seem likely both simpler and more consistent overall? (where previously I had mistakenly equated "static const" == "literal") -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From gdr at integrable-solutions dot net 2005-05-16 02:54 --- Subject: Re: static_cast falsely allows const to be cast away "schlie at comcast dot net" <[EMAIL PROTECTED]> writes: | --- Additional Comments From schlie at comcast dot net 2005-05-16 02:44 --- | (In reply to comment #5) | > Subject: Re: static_cast falsely allows const to be cast away | > | > Yup, string literal should have type 'const char *'. | > | | > | I believe 'static const char []' would seem most correct? | > | > "static" is not part of the type. The ty[e of a string literal is | > "const char[N]", N being its sizeof. There is no if no but. | > Similar rule for wide string literal. | | Then maybe GCC needs to broaden it's view of what information | needs to be considered a type qualifier at least internally; as a | storage specification can certainly restrict an object's permissible | use and access, as such should be recorded and maintained as a | qualifier for all objects, and pointers/references. That is your view. However, not because GCC implements the ISO C++ view of types, means that GCC has a narrow view of a type is. I suspect that part of your speculation is based on unfamiliarity with both the C++ type system and the GCC internal notion of types. | A literal string is not simply a 'const char [N]' object, as a | literal value may not be specified as a target of an assignment, | directly or indirectly though a pointer cast to a non-const object | reference, unlike as a plain old 'const' objects may be. But, a plain old 'const' object cannot be a target of an assignment. There is no different there -- and certainly "static" does not imply a difference there -- so the basis of your argument seems fragile to begin with. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug c++/19894] pointer-to-void member not rejected in template
--- Additional Comments From donaldc at csgsolar dot com dot au 2005-05-16
03:06 ---
> The third paragraph of [8.3.3] aka [dcl.mptr] says:
>
> A pointer to member shall not point to a static member of a class (9.4),
> a member with reference type, or "cv void."
It can be equal to null, though. The following should all compile:
a=0;
if (a==0) { } // always true
if (a!=0) {} // always false
I don't think there's a bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19894
[Bug bootstrap/21556] [4.0/4.1 Regression] TLS failures on 4.0 branch
--- Additional Comments From rth at gcc dot gnu dot org 2005-05-16 03:23 --- Not a duplicate entirely. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | Summary|[4.0/4.1 Regression] ia64- |[4.0/4.1 Regression] TLS |hpux bootstrap fails on |failures on 4.0 branch |mainline, TLS failures on | |4.0 branch | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21556
[Bug bootstrap/21556] [4.0/4.1 Regression] TLS failures on 4.0 branch
-- What|Removed |Added Attachment #8898|z |proposed patch description|| Attachment #8898|z |d-21556-1 filename|| Attachment #8898 is|0 |1 patch|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21556
[Bug bootstrap/21556] [4.0/4.1 Regression] TLS failures on 4.0 branch
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-16 03:25:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21556
[Bug target/18655] Incorrect data in .debug_frame section for PowerPC
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-16 04:32 --- Subject: Bug 18655 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-16 04:32:38 Modified files: gcc: ChangeLog dwarf2out.c Log message: Backport: 2005-05-09 Mark Mitchell <[EMAIL PROTECTED]> PR 18655 * dwarf2out.c (output_call_frame_info): Use DWARF2_FRAME_REG_OUT before outputting DWARF_FRAME_RETURN_COLUMN. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.246&r2=2.7592.2.247 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.570.2.7&r2=1.570.2.8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18655
[Bug c++/20475] static_cast falsely allows const to be cast away
--- Additional Comments From schlie at comcast dot net 2005-05-16 05:07
---
(In reply to comment #7)
> Subject: Re: static_cast falsely allows const to be cast away
> That is your view. However, not because GCC implements the ISO C++
> view of types, means that GCC has a narrow view of a type is. I
> suspect that part of your speculation is based on unfamiliarity with
> both the C++ type system and the GCC internal notion of types.
- but apparently inadequate to express the necessary differentiation between
constant and literal objects, as needed to be tracked by a compiler for
these languages?
> | A literal string is not simply a 'const char [N]' object, as a
> | literal value may not be specified as a target of an assignment,
> | directly or indirectly though a pointer cast to a non-const object
> | reference, unlike as a plain old 'const' objects may be.
>
> But, a plain old 'const' object cannot be a target of an assignment.
> There is no different there -- and certainly "static" does not imply a
> difference there -- so the basis of your argument seems fragile to
> begin with.
- subtle possibly, but not fragile; the following simple program illustrates
the problem, where if hypothetically 'literal' were a valid qualifier,
then the problem would be easy to solve, and also flexibly enable the
definition of functions which accept and return references to literals,
as being distinct from const, where const means simply not writeable
presently, not necessary never (i.e. can't ever assign to references,
which is what literal semantics would seem to dictate.):
#include
int main (void)
{
// non-const pointers to literals should at least warn,
// and assignments to literals should generate an error.
char *cp = "(a)"; // compiles without warning/error (literal*)?
// ((char *)cp)[1] = 't';// compiles without warning/error -> bus error!
printf(cp); // dies above if uncommented, otherwise "(a)"
char ca[4] = "(b)"; // compiles without warning/error.
((char *)ca)[1] = 't';// compiles without warning/error.
printf(ca); // outputs "(t)", as expected.
// as above.
const char *ccp = "(c)"; // compiles without warning/error (literal*)
// ((char *)ccp)[1] = 't'; // compiles without warning/error -> bus error!
printf(ccp); // dies above if uncommented, otherwise "(a)"
const char cca[4] = "(d)";// compiles without warning/error.
((char *)cca)[1] = 't'; // compiles without warning/error.
printf(cca); // outputs "(t)", as expected.
// as above.
static const char sca[4] = "(e)"; // compiles w/o warning/error (literal*)
// ((char *)sca)[1] = 't'; // compiles without warning/error, (bus error)!
printf(sca); // dies above if uncommented, otherwise "(a)"
// as above.
"(f)";// compiles without warning/error (literal*)
// ((char *)"(f)")[1] = 't'; // compiles without warning/error -> bus error!
printf("(f)");// dies above if uncommented, otherwise "(a)"
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20475
[Bug AWT/21604] New: strange refresh behavior when moving mouse
I'm using the applet here: http://www.chessgames.com/perl/chessgame?gid=1069669 with gcjappletviewer. (As of this writing I needed a patch to make this work at all, see the classpath-patches list.) When the applet window first comes up, if I move the mouse from the applet window into another unrelated window, the applet window will do a full refresh. If I move the mouse from the applet window to the desktop, nothing special happens. (The same thing happens when moving the mouse from a window into the applet, but again does not happen when moving from the desktop into the applet.) After I make a move in the applet, this refresh behavior stops. -- Summary: strange refresh behavior when moving mouse Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: AWT AssignedTo: fitzsim at redhat dot com ReportedBy: tromey at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21604
