--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Keywords||accepts-invali
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-29 07:05 ---
*** This bug has been marked as a duplicate of 16617 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-29 07:05 ---
*** Bug 33934 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-29 07:05 ---
*** This bug has been marked as a duplicate of 16617 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-29 07:05 ---
*** Bug 24118 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #17 from pinskia at gcc dot gnu dot org 2009-04-29 07:09
---
*** Bug 39956 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-29 07:09 ---
This was just (a little over three weeks ago) fixed on the trunk.
*** This bug has been marked as a duplicate of 26693 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-04-29
07:29 ---
The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll,
libssp-x.dll, etc) that are built as part of gcc
Danny
--
dannysmith at users dot sourceforge dot net changed:
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-04-29 07:38 ---
(In reply to comment #2)
> The same problem will occur for all dll's (libstdc++-x,dll, libgfortran-x.dll,
> libssp-x.dll, etc) that are built as part of gcc
> Danny
That's correct. We have to find a way to install t
--- Comment #11 from vvv at ru dot ru 2009-04-29 07:46 ---
(In reply to comment #8)
> From config/i386/i386.c:
> /* AMD Athlon works faster
>when RET is not destination of conditional jump or directly preceded
>by other jump instruction. We avoid the penalty by inserting NOP jus
--- Comment #12 from vvv at ru dot ru 2009-04-29 07:55 ---
(In reply to comment #9)
> So that explains it, Use -Os or attribute cold if you want NOPs to be gone.
But my measurements on Core 2 Duo P8600 show that
push %ebp
mov %esp,%ebp
leave
ret
_faster_ then
push %ebp
mov %esp,%eb
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-29 08:34 ---
Subject: Bug 39565
Author: rguenth
Date: Wed Apr 29 08:34:21 2009
New Revision: 146928
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146928
Log:
2009-04-29 Anmol P. Paralkar
PR target/39565
--- Comment #4 from jon_y at users dot sourceforge dot net 2009-04-29
08:37 ---
(In reply to comment #3)
> (In reply to comment #2)
> > The same problem will occur for all dll's (libstdc++-x,dll,
> > libgfortran-x.dll,
> > libssp-x.dll, etc) that are built as part of gcc
> > Danny
>
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-04-29 08:58
---
Shorter testcase, which still includes , though.
It crashes with "-O" and above:
==
#include
struct A
{
virtual ~A() {}
};
struct B : A
{
virtual ~B() { foo();
--- Comment #6 from paolo dot carlini at oracle dot com 2009-04-29 09:17
---
Jon, patch looks generally good to me, can you please send it to the mailing
list for higher visibility? Then we can commit it and close this annoying issue
once and for all ;)
--
http://gcc.gnu.org/bugzil
--- Comment #4 from matz at gcc dot gnu dot org 2009-04-29 09:22 ---
I didn't enable it explicitely, but Janis neither (according to the
testresults post), so it's probably default. But I did not use some
other options, in particular the --with-cpu=default32, so I'm rechecking
with Jani
--- Comment #13 from jakub at gcc dot gnu dot org 2009-04-29 09:32 ---
You are benchmarking something completely unrelated.
What really matters is how code that has 4 branches/calls in one 16-byte block
is able to predict all those branches. And Core2 similarly to various AMD CPUs
is no
--- Comment #14 from jakub at gcc dot gnu dot org 2009-04-29 10:12 ---
Also, couldn't we use the information computed by compute_alignments and
assume CODE_LABELs are aligned?
Probably would need to add label_to_max_skip (rtx) function to final.c,
so that not just label_to_alignment, but
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-29 10:39 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-04-29 10:39 ---
Subject: Bug 39941
Author: rguenth
Date: Wed Apr 29 10:39:26 2009
New Revision: 146948
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146948
Log:
2009-04-29 Richard Guenther
PR tree-optimization/
--- Comment #5 from matz at gcc dot gnu dot org 2009-04-29 11:07 ---
Pff, I still can't reproduce the testsuite failures, but I can reproduce the
ICE on the testcase from the initial comment. rs6000.c needs to handle
SSA_NAMEs now. I'm currently regstrapping this:
Index: config/rs6000
--- Comment #10 from joseph at codesourcery dot com 2009-04-29 11:33
---
Subject: Re: [4.5 Regression] Revision 146817 caused
unaligned access in gcc.dg/torture/pr26565.c
On Wed, 29 Apr 2009, matz at gcc dot gnu dot org wrote:
> The user should have the possibility to announce the u
--- Comment #11 from matz at gcc dot gnu dot org 2009-04-29 11:38 ---
Thanks for the clarification. So there indeed is only one issue, that the
temporary has an aligned type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
--- Comment #5 from bje at gcc dot gnu dot org 2009-04-29 12:06 ---
I think this PR can now be closed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from bje at gcc dot gnu dot org 2009-04-29 12:08 ---
Fixed for 4.5.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #31 from paolo dot carlini at oracle dot com 2009-04-29 11:53
---
Hans-Peter, any news about your patch? If I understand correctly, when it will
be in, the testsuite will be again clean.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39644
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-29 11:52 ---
In C:
int foo (int i)
{
int j;
switch (i)
{
case -__INT_MAX__ - 1 ... -1:
j = 6;
break;
case 0:
j = 5;
break;
case 1 ... __INT_MAX__:
j = 4;
break;
}
retur
--- Comment #4 from reichelt at gcc dot gnu dot org 2009-04-29 12:33
---
Confirmed. Reduced testcase (crashes with "-O"):
==
struct A
{
virtual ~A() {}
};
struct B : A
{
virtual ~B() { foo(); }
void foo();
};
struct C : B
{
C(const C& c) :
--- Comment #10 from bangerth at gmail dot com 2009-04-29 12:51 ---
There is really nothing much that can be done within the current C++
standard. In C, NULL is defined as
(void*)0
which can be converted to any other pointer and so is clearly marked
as a pointer. The compiler can then
--- Comment #4 from manu at gcc dot gnu dot org 2009-04-29 13:16 ---
(In reply to comment #3)
>
> Note that getInt is completely inlined and there is no location involving
> that function available anymore :/ The difficulties of C++ and late
> diagnostics ...
>
I wonder what Clang+LL
--- Comment #1 from manu at gcc dot gnu dot org 2009-04-29 13:21 ---
Confirmed.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #11 from l dot lunak at suse dot cz 2009-04-29 13:21 ---
(In reply to comment #10)
> As a consequence, since NULL can not in an obvious way be a pointer, there is
> no obvious warning that can be generated.
Of course there is. NULL with gcc is not 0, 0L or (void*)0, it is _
--- Comment #1 from manu at gcc dot gnu dot org 2009-04-29 13:23 ---
Confirmed.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #9 from ramana at gcc dot gnu dot org 2009-04-29 13:48 ---
4.2.x is now closed. Since this appears to work on 4.3.1, could you confirm if
this is still a problem with an eabi toolchain of more recent vintage ?
--
ramana at gcc dot gnu dot org changed:
What
--- Comment #6 from hjl dot tools at gmail dot com 2009-04-29 13:50 ---
(In reply to comment #5)
> Pff, I still can't reproduce the testsuite failures, but I can reproduce the
> ICE on the testcase from the initial comment. rs6000.c needs to handle
> SSA_NAMEs now. I'm currently regstr
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-29 13:54 ---
Created an attachment (id=17778)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17778&action=view)
gcc44-pr39666.patch
Fix I'm going to bootstrap/regtest soon.
--
jakub at gcc dot gnu dot org changed:
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-29 13:58 ---
Could you check with a version of more recent vintage and provide more
information like the svn revision number ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2009-04-29 14:04 ---
That's by design.
Obviously there are so many possible combinations that you can't exhaustively
test them all, that's why this test randomly chooses some.
You can pass -n count to the generator to generate more (or few
--- Comment #8 from hjl dot tools at gmail dot com 2009-04-29 14:04 ---
On Linux/x86-64, I got
gcc -c -o pp_sort.o -DSPEC_CPU -DNDEBUG -DPERL_CORE -O3 -ffast-math
-funroll-loops -DSPEC_CPU_LP64 -DSPEC_CPU_LINUX_X64 pp_sort.c
pp_sort.c: In function 'S_qsortsv':
pp_sort.c:1
--- Comment #9 from hjl dot tools at gmail dot com 2009-04-29 14:06 ---
(In reply to comment #8)
> On Linux/x86-64, I got
>
> gcc -c -o pp_sort.o -DSPEC_CPU -DNDEBUG -DPERL_CORE -O3 -ffast-math
> -funroll-loops -DSPEC_CPU_LP64 -DSPEC_CPU_LINUX_X64 pp_sort.c
> pp_sort.c: I
--- Comment #10 from rguenther at suse dot de 2009-04-29 14:06 ---
Subject: Re: [4.5 Regression] Revision 146831 failed
SPEC CPU 2006
On Wed, 29 Apr 2009, hjl dot tools at gmail dot com wrote:
> --- Comment #8 from hjl dot tools at gmail dot com 2009-04-29 14:04
> ---
> On
--- Comment #4 from jakub at gcc dot gnu dot org 2009-04-29 14:07 ---
This is a regression from 3.4.x to 4.0.x BTW.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from hjl dot tools at gmail dot com 2009-04-29 14:10
---
(In reply to comment #10)
>
> 2009-04-28 Richard Guenther
>
> * tree-vect-loop.c (get_initial_def_for_induction): Use
> correct types for pointer increment.
>
That is before and with revisio
--- Comment #12 from rguenther at suse dot de 2009-04-29 14:12 ---
Subject: Re: [4.5 Regression] Revision 146831 failed
SPEC CPU 2006
On Wed, 29 Apr 2009, hjl dot tools at gmail dot com wrote:
> --- Comment #11 from hjl dot tools at gmail dot com 2009-04-29 14:10
> ---
> (I
--- Comment #2 from dominiq at lps dot ens dot fr 2009-04-29 14:12 ---
I wonder if this not a duplicate of pr36683.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39286
gcc 4.5 r146933
gcc -std=gnu99 -O2 -floop-block -c matmul_c4.c
/svn/compilers/gcc/libgfortran/generated/matmul_c4.c: In function 'matmul_c4':
/svn/compilers/gcc/libgfortran/generated/matmul_c4.c:79: internal compiler
error: in expand_scalar_variables_expr, at graphite.c:4262
Please submit a full
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-29 14:17 ---
With -O2 VRP should (since 4.4) "fix" this as well. That said, newer GCC
no longer need a default label.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39666
--- Comment #3 from dominiq at lps dot ens dot fr 2009-04-29 14:19 ---
I have modified the code referenced in pr36683 as:
PROGRAM calls
IMPLICIT NONE
INTEGER :: a(2), b(3), c(6), n , i
c = myfunc(a,b)
WRITE(*,*) "c:",c!! gives "c: 1 2 3 4 5 6"
n = 5
c = 0
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-04-29 14:20 ---
The only expected fails left should now be
FAIL: gcc.dg/pr34989-1.c (internal compiler error)
FAIL: gcc.dg/pr34989-1.c (internal compiler error)
FAIL: gcc.dg/pr34989-1.c (test for excess errors)
FAIL: gcc.dg/pr34989
--- Comment #2 from dominiq at lps dot ens dot fr 2009-04-29 14:20 ---
pr39286 is a duplicate of this one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36683
--- Comment #1 from linuxl4 at sohu dot com 2009-04-29 14:21 ---
Created an attachment (id=17779)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17779&action=view)
the source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39957
FAIL: libgomp.c++/task-4.C -O (internal compiler error)
FAIL: libgomp.c++/task-4.C -O (internal compiler error)
FAIL: libgomp.c++/task-4.C -O (test for excess errors)
FAIL: libgomp.c++/task-4.C -O (test for excess errors)
/space/rguenther/src/svn/trunk/libgomp/testsuite/libgomp.c++/task-4.
FAIL: gcc.dg/pr34989-1.c (internal compiler error)
FAIL: gcc.dg/pr34989-1.c (internal compiler error)
FAIL: gcc.dg/pr34989-1.c (test for excess errors)
FAIL: gcc.dg/pr34989-1.c (test for excess errors)
/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/pr34989-2.c: In function
'syslogd_main':^M
/
FAIL: gcc.dg/struct/wo_prof_double_malloc.c (internal compiler error)
FAIL: gcc.dg/struct/wo_prof_double_malloc.c (internal compiler error)
FAIL: gcc.dg/struct/wo_prof_double_malloc.c (test for excess errors)
FAIL: gcc.dg/struct/wo_prof_double_malloc.c (test for excess errors)
/space/rguenther/src
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-04-29 14:27
---
Three actually.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39958
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
Fixed.
--
rguenth at gcc dot gnu dot org c
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39958
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959
--- Comment #10 from dominiq at lps dot ens dot fr 2009-04-29 14:28 ---
> This may be a duplicate of PR36683(?).
It is not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36754
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-29 14:38 ---
The new code has a value of max_idx of DTOR_END - DTOR_LIST - 1. You might want
to see why your implementation has a value of max_idx > 1. It doesn't appear to
be a target bug yet - Please check this and get back with
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-29 14:40 ---
(In reply to comment #1)
> That's by design.
> Obviously there are so many possible combinations that you can't exhaustively
> test them all, that's why this test randomly chooses some.
> You can pass -n count to the
Compiling to-be-attached snippet with -g does not seem to emit sufficient debug
info for vars defined inside ctor bodies; neither is gdb able to display info
for them, nor do their names appear in the debug info sections.
Versions I've tried this with: 4.2.3, 4.3.1 and 4.3.2. Using i686 instead al
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-29 14:44 ---
(In reply to comment #2)
>
> If it is truly random, shouldn't someone on Linux/x86-64 run into it
> sometimes?
it uses the same seed each time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39952
--- Comment #1 from thb at openoffice dot org 2009-04-29 14:45 ---
Created an attachment (id=17780)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17780&action=view)
test file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39961
Dear,
There may be a substraction or other arithmetic operation bug in the gcc
compiler when one of the operands is a constant which is defined with another
constant and a value.
I've discovered the bug in gcc version v4.1.2-44 which is the default gcc
compiler for the RedHat Enterprise Linux v5.
--- Comment #8 from hjl at gcc dot gnu dot org 2009-04-29 14:55 ---
Subject: Bug 39941
Author: hjl
Date: Wed Apr 29 14:54:54 2009
New Revision: 146972
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146972
Log:
2009-04-29 H.J. Lu
Backport from mainline:
2009-0
--- Comment #13 from hjl at gcc dot gnu dot org 2009-04-29 14:55 ---
Subject: Bug 39937
Author: hjl
Date: Wed Apr 29 14:54:54 2009
New Revision: 146972
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146972
Log:
2009-04-29 H.J. Lu
Backport from mainline:
2009-
--- Comment #6 from hjl at gcc dot gnu dot org 2009-04-29 14:55 ---
Subject: Bug 39565
Author: hjl
Date: Wed Apr 29 14:54:54 2009
New Revision: 146972
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146972
Log:
2009-04-29 H.J. Lu
Backport from mainline:
2009-0
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-29 14:56 ---
(In reply to comment #3)
> (In reply to comment #2)
> >
> > If it is truly random, shouldn't someone on Linux/x86-64 run into it
> > sometimes?
>
> it uses the same seed each time.
>
Why can't we use the current
--- Comment #5 from jakub at gcc dot gnu dot org 2009-04-29 14:59 ---
Yeah, and that's because otherwise reproduceability would be a nightmare.
We even use the same pseudo-random generator on all hosts to have as few
differences as possible.
It is certainly possibility to add a -sSEED op
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-29 14:59 ---
This is not a bug, this is how the C preprocessor works.
#define Q_dest 0x00
#define Q_source Q_dest + 1
#define Q_len Q_source + 1
#define Q_T_tpdu Q_len + 2
#define Q_T_dest
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-29 15:05 ---
This is fixed AFAIK in 4.4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39961
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-04-29 15:06
---
Subject: Bug 39937
Author: rguenth
Date: Wed Apr 29 15:05:22 2009
New Revision: 146973
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146973
Log:
2009-04-29 Richard Guenther
PR middle-end/39937
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-04-29 15:06
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #32 from carlos at codesourcery dot com 2009-04-29 15:07
---
No, you are absolutely right and the tree dumps confirm it. I thought it might
be possible to trigger a reference by using the right flags, but to no avail,
the compiler always folds the if-then-else to __signbit.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|4.0.2 4.4.0 4.3.3 |4.0.2 4.4.0
Target Milestone|4.2.5 |4.3.3
h
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-29 15:09 ---
(In reply to comment #2)
> This is fixed AFAIK in 4.4.0.
>
And in 4.3.3.
*** This bug has been marked as a duplicate of 27574 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #32 from pinskia at gcc dot gnu dot org 2009-04-29 15:09
---
*** Bug 39961 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36194
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27367
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33131
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36278
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36634
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35100
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35432
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37014
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37101
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37389
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34037
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35737
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37809
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38007
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28102
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35405
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37142
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28513
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.5 |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26243
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-29 15:22 ---
Does http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01619.html fix this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39940
1 - 100 of 193 matches
Mail list logo
