--- Comment #10 from bonzini at gnu dot org 2009-08-05 06:09 ---
preprocessed testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40952
--- Comment #8 from dannysmith at users dot sourceforge dot net 2009-08-05
04:55 ---
(In reply to comment #6)
> (In reply to comment #5)
>
> > Applying Dave Korn's patch mentioned in Comment #2, and linking against
> > libstdc++.dll, I get this with your original testcaase:
> >
> > Ex
--- Comment #3 from sebpop at gmail dot com 2009-08-05 04:42 ---
Subject: Re: [graphite] slow compilation
On Tue, Aug 4, 2009 at 17:44, rguenth at gcc dot gnu dot
org wrote:
> Eh - where's that exponential time complexity? ...
The code generation of Graphite can be exponential, didn't
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2009-08-05 03:19
---
Fixed on 4.4 and 4.5, closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-08-05 03:18
---
Subject: Bug 40853
Author: jvdelisle
Date: Wed Aug 5 03:17:52 2009
New Revision: 150477
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150477
Log:
2009-08-04 Jerry DeLisle
PR libfortran/4085
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-08-05 03:15
---
Subject: Bug 40853
Author: jvdelisle
Date: Wed Aug 5 03:15:18 2009
New Revision: 150476
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150476
Log:
2009-08-04 Jerry DeLisle
PR libfortran/40853
On Linux/ia64, revision 150465 gave:
FAIL: gfortran.dg/c_by_val_1.f -O0 execution test
FAIL: gfortran.dg/c_by_val_1.f -O1 execution test
FAIL: gfortran.dg/c_by_val_1.f -O2 execution test
FAIL: gfortran.dg/c_by_val_1.f -O3 -fomit-frame-pointer execution test
FAIL: gfortran.dg/c_by_val_1.f
--- Comment #2 from paolo dot carlini at oracle dot com 2009-08-05 01:06
---
A Segmentation fault certainly isn't a library issue.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from manu at gcc dot gnu dot org 2009-08-04 23:52 ---
FIXED in GCC 4.5. Thanks for the report.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2009-08-04 23:51 ---
Subject: Bug 36069
Author: manu
Date: Tue Aug 4 23:51:07 2009
New Revision: 150471
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150471
Log:
2009-08-05 Manuel López-Ibáñez
PR c++/36069
cp/
--- Comment #9 from sje at cup dot hp dot com 2009-08-04 23:48 ---
Well, it got a lot further using the patch but it didn't completely bootstrap.
The compiler built but while building libstdc++-v3 I got:
/proj/opensrc/nightly/src/trunk/libstdc++-v3/libsupc++/eh_ptr.cc: In function
'std
--- Comment #32 from manu at gcc dot gnu dot org 2009-08-04 23:42 ---
Since the patch was reverted, this is still a regression in all open branches.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from manu at gcc dot gnu dot org 2009-08-04 23:32 ---
The C parser points to the start of the second declaration, which is not very
good either.
pr36888.c:5:1: error: two or more data types in declaration specifiers
In the c-parser, we can probably special case the struc
--- Comment #1 from lucier at math dot purdue dot edu 2009-08-04 23:15
---
bootstrap completes without --enable-gather-detailed-mem-stats
--
lucier at math dot purdue dot edu changed:
What|Removed |Added
---
with this compiler:
Mon Aug 3 16:57:15 UTC 2009 (revision 150373)
with this configure and build:
/bin/rm -rf *; ../../mainline/configure --enable-checking=release
--prefix=/pkgs/gcc-mainline-mem-stats --enable-languages=c,c++
--enable-gather-detailed-mem-stats -enable-stage1-languages=c,c++; ma
--- Comment #3 from manu at gcc dot gnu dot org 2009-08-04 22:47 ---
We should really upgrade bugzilla to version 3.0
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-04 22:44 ---
Eh - where's that exponential time complexity? ...
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from manu at gcc dot gnu dot org 2009-08-04 22:42 ---
(In reply to comment #7)
>
> It might be an improvement if GCC gave different diagnostics for the case
> where
> a suitable conversion sequence exists but cannot be used because it would
> create an rvalue which canno
--- Comment #4 from burnus at gcc dot gnu dot org 2009-08-04 22:36 ---
FIXED on the trunk.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Statu
Take the testcase for 39495, and add the "schedule(dynamic)" clause to the for
loop:
#include
#include
void foo(unsigned ub, unsigned *array)
{
unsigned i;
// test passes for N >= 1
#define N 0
#pragma omp for schedule(dynamic)
for (i = ub; i > N; i -=2) {
array[i] = i;
--- Comment #8 from bonzini at gnu dot org 2009-08-04 22:30 ---
Created an attachment (id=18304)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18304&action=view)
plausible patch
The patch adds back the mode of operation corresponding to
promote_nominal_mode's assignment. It turn
--- Comment #7 from sje at cup dot hp dot com 2009-08-04 21:23 ---
I think I got things backwards in my last comment. In the old code
promoted_nominal_mode was set by a call to promote_mode which had the ifdef
POINTERS_EXTEND_UNSIGNED in it to set unsignedp for REFERENCE and POINTER
typ
--- Comment #6 from sje at cup dot hp dot com 2009-08-04 21:04 ---
I am currently looking at assign_parm_setup_reg, in the old code with test2.c,
we set promoted_nominal_mode being set to DImode and then we get a conversion
because promoted_nominal_mode != data->promoted_mode. In the ne
--- Comment #5 from jakub at gcc dot gnu dot org 2009-08-04 20:56 ---
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00226.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from dodji at gcc dot gnu dot org 2009-08-04 20:01 ---
Fixed in 4.5 and 4.4 branches. Won't be fixed in 4.3 as this fix depends on the
fix for PR c++/37971, and that later fix hasn't been applied to the 4.3 branch.
Can this bug be closed still ?
--
http://gcc.gnu.org
--- Comment #3 from dodji at gcc dot gnu dot org 2009-08-04 19:59 ---
Subject: Bug 39987
Author: dodji
Date: Tue Aug 4 19:59:48 2009
New Revision: 150468
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150468
Log:
2009-08-04 Dodji Seketeli
gcc/cp/ChangeLog:
PR c++/39
--- Comment #1 from pedro dot lamarao at gmail dot com 2009-08-04 19:55
---
Created an attachment (id=18303)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18303&action=view)
Preprocessed source that triggered the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40966
I'm seeing the following ICE with current a cxx0x-lambda-branch compiler.
/opt/gcc-lambda/bin/g++ -Iinclude -I../cxx_device/include
-I../cxx_network/include/network -MD -std=c++0x -save-temps -Wall -Werror -O0
-g3 -fPIC -pthread -include src/throw_select_server/config.hpp -c -o
bin/throw_select_s
--- Comment #2 from dodji at gcc dot gnu dot org 2009-08-04 19:50 ---
Subject: Bug 39987
Author: dodji
Date: Tue Aug 4 19:49:48 2009
New Revision: 150467
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150467
Log:
2009-08-04 Dodji Seketeli
gcc/cp/ChangeLog:
PR c++/39
--- Comment #8 from ubizjak at gmail dot com 2009-08-04 19:27 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #7 from uros at gcc dot gnu dot org 2009-08-04 19:25 ---
Subject: Bug 40577
Author: uros
Date: Tue Aug 4 19:25:05 2009
New Revision: 150466
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150466
Log:
Backport from mainline:
2009-08-03 Uros Bizjak
--- Comment #1 from jv244 at cam dot ac dot uk 2009-08-04 19:23 ---
Created an attachment (id=18302)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18302&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40965
the attached testcase compiles in about 3s with
gfortran -c -ffree-form -O3 -ffast-math -ftree-vectorize -funroll-loops
-march=native -ftime-report bug.f90
but requires about 130s adding -fgraphite-identity to the options
GRAPHITE loop transforms: 123.82 (97%) usr 0.59 (89%) sys 124.37 (97%)
--- Comment #7 from jwakely dot gcc at gmail dot com 2009-08-04 17:48
---
(In reply to comment #5)
> Here's a small testcase:
>
> struct B {};
> struct D : B {};
>
> struct S {
> int foo(B* & taskData);
> };
>
> int i = S().foo((D*)0);
>
--- Comment #5 from sje at cup dot hp dot com 2009-08-04 17:46 ---
Created an attachment (id=18301)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18301&action=view)
Better test case
Here is a better test case that actually shows bad code being generated. In
r150335, we extend r32
--- Comment #3 from burnus at gcc dot gnu dot org 2009-08-04 17:36 ---
Subject: Bug 40949
Author: burnus
Date: Tue Aug 4 17:35:59 2009
New Revision: 150465
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150465
Log:
2009-08-04 Tobias Burnus
PR fortran/40949
*
--- Comment #4 from sje at cup dot hp dot com 2009-08-04 17:09 ---
Created an attachment (id=18300)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18300&action=view)
Testcase
This test case shows the difference in generated code between r150335 and
r150336. It does not actually ge
--- Comment #8 from dodji at gcc dot gnu dot org 2009-08-04 17:06 ---
Fixed in 4.3 as well.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #7 from dodji at gcc dot gnu dot org 2009-08-04 16:59 ---
Subject: Bug 39706
Author: dodji
Date: Tue Aug 4 16:59:11 2009
New Revision: 150462
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150462
Log:
2009-08-04 Dodji Seketeli
gcc/cp/ChangeLog:
PR debug/
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-08-04 16:54 ---
Right. The number in identifiers I see are different, of course, but
what happens is this. Early SRA replaces structure b.3 with
SR.4_25. In BB2, it is assigned into from parameter b:
SR.4_25 = b._M_value;
This
--- Comment #7 from paolo dot carlini at oracle dot com 2009-08-04 16:51
---
Nope...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Assigned
--- Comment #6 from paolo dot carlini at oracle dot com 2009-08-04 16:50
---
Never mind, tried with a non-checking GCC...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #6 from paolo dot carlini at oracle dot com 2009-08-04 16:43
---
Seems easy to fix now...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2009-08-04 16:35
---
This one doesn't reproduce anymore in mainline.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
--- Comment #2 from manu at gcc dot gnu dot org 2009-08-04 16:23 ---
Confirmed in trunk.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from burnus at gcc dot gnu dot org 2009-08-04 16:14 ---
The issue is that the expression is an array ("expr->rank > 0") but the symbol
itself is not, only it's component.
==16545== Invalid read of size 4
==16545==at 0x55343F: gfc_conv_procedure_call (trans-expr.c:244
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |target
GCC ta
--- Comment #3 from burnus at gcc dot gnu dot org 2009-08-04 16:09 ---
Thomas, as you know a bit about the array descriptor, can you have a look? The
problem seems to be in libgfortran/intrinsics/iso_c_binding.c's c_f_pointer*
Simplified test case:
One: 1 2 -1 -2
Two: 1 2 2 -1
--- Comment #6 from manu at gcc dot gnu dot org 2009-08-04 16:02 ---
This is still valid and it does not depend on -fpermissive. It would be
interesting to see what is the output from other C++ compilers.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #13 from manu at gcc dot gnu dot org 2009-08-04 15:52 ---
FIXED in GCC 4.5.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #12 from manu at gcc dot gnu dot org 2009-08-04 15:51 ---
Subject: Bug 16696
Author: manu
Date: Tue Aug 4 15:51:12 2009
New Revision: 150461
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150461
Log:
2009-08-04 Manuel López-Ibáñez
PR c++/16696
cp/
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-04 15:50 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
% cat bla.c
struct alloc2 {
int bla;
char * __restrict data;
char * __restrict data2;
};
struct alloc2 b;
void * f (void)
{ return b.data;}
% ./cc1 -O2 bla.c
bla.c:12:1: internal compiler error: in insert_vi_for_tree, at
tree-ssa-structalias.c:2586
Problem is that the struct contains
--- Comment #1 from rohou at brandeis dot edu 2009-08-04 15:22 ---
Created an attachment (id=18299)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18299&action=view)
Source file to cause the segfault
I used option -save-temps, but could not find a *.i file, so I have attached
the *
(first bug I'm reporting, apologies if duplicate or info missing)
== COMPILE-TIME OUTPUT ==
gfortran -I. -Isrc/ -v -save-temps -Wall -fbounds-check -O2 -ffree-form -c
-o main.o /gusr/alr99/cluster/workspace/helloworld/main.f90
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured w
--- Comment #3 from sje at cup dot hp dot com 2009-08-04 14:59 ---
No, the patch in comment #2 did not fix the problem. I did a non-bootstrap
build followed by a testsuite run hoping I would get a failure there with a
nice small test case but I didn't get any unexpected failures.
--
--- Comment #4 from joseph at codesourcery dot com 2009-08-04 14:54 ---
Subject: Re: POSIX requires that option -D have a lower precedence
than -U
On Tue, 4 Aug 2009, vincent at vinc17 dot org wrote:
> There would the possibility to have a POSIX mode implied by c99, but I don't
> thi
--- Comment #2 from reuter at physik dot uni-freiburg dot de 2009-08-04
14:25 ---
Created an attachment (id=18298)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18298&action=view)
iso_varying_string.f90 needed for the example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40
--- Comment #1 from reuter at physik dot uni-freiburg dot de 2009-08-04
14:25 ---
Created an attachment (id=18297)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18297&action=view)
test program for the bug report
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40962
The following test code below (which works with the NAG 5.2 Fortran Compiler)
seems to choke over the conversion f-allocatable -> cptr -> fptr ->
f-allocatable. With NAG the output should be:
--
nagfor tab3.f90 -o tab3 && ./tab3
NAG Fortran Compiler
--- Comment #1 from dodji at gcc dot gnu dot org 2009-08-04 14:21 ---
Submitted a patch to http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00185.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39987
--- Comment #2 from hjl dot tools at gmail dot com 2009-08-04 14:15 ---
(In reply to comment #1)
> We enter standard_sse_constant_opcode with:
>
> (const_vector:V4DI [
> (const_int -1 [0x])
> (const_int -1 [0x])
> (const_int -1 [0x
--- Comment #6 from mikpe at it dot uu dot se 2009-08-04 14:07 ---
Hang on, the test case looks invalid:
> ReadCfgFile (char *cfg_file)
> {
> void *conf_handler;
> int i;
> struct sockaddr_in nsaddr_list[0];
> char *nserver_str;
> qp_getconf_array_str (conf_handler, "Nameserve
We list a lot of library initialization functions at
http://gcc.gnu.org/onlinedocs/gfortran/Non_002dFortran-Main-Program.html
however, _gfortran_set_fpe(int) is missing.
Currently, it is set via -ffpe-trap=<*>
Possible values are:
/* Bitmasks for the various FPE that can be enabled. */
#define
--- Comment #3 from jakub at gcc dot gnu dot org 2009-08-04 14:01 ---
And the GCC behavior makes much more sense than the POSIX required for c99.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40960
--- Comment #5 from mikpe at it dot uu dot se 2009-08-04 13:58 ---
Confirmed with gcc-4.3-20090802, gcc-4.4-20090728, and gcc-4.5-20090730.
Passing -mtune=xscale to gcc prevents the ICE.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
---
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40957
--- Comment #7 from andriys at gmail dot com 2009-08-04 13:53 ---
Created an attachment (id=18296)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18296&action=view)
Yet another test case
This test checks whether main executable and dll share common
abi::__cxa_eh_globals structure.
--- Comment #17 from mkuvyrkov at gcc dot gnu dot org 2009-08-04 13:43
---
I'll try the above two patches and will report in a couple of days.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
--- Comment #6 from andriys at gmail dot com 2009-08-04 13:41 ---
(In reply to comment #5)
> I cannot comment on the build of libsdc++.dll in the mingw 4.4.0 release since
> I have not looked at that source.
There is a patch file that is shipped along with the mingw 4.4.0 build
instruct
--- Comment #16 from bergner at gcc dot gnu dot org 2009-08-04 13:35
---
There have been many patches posted, but most have caused serious performance
degradations on power. However, the two latest patches to reload do not. They
are:
1) http://gcc.gnu.org/ml/gcc-patches/2009-07/msg0
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
|dot com
--- Comment #2 from vincent at vinc17 dot org 2009-08-04 13:29 ---
There would the possibility to have a POSIX mode implied by c99, but I don't
think having different behaviors would be a good idea. IMHO, Makefiles should
be fixed to stick to POSIX.
Also, portable Makefiles, i.e. that w
--- Comment #1 from ubizjak at gmail dot com 2009-08-04 13:21 ---
We enter standard_sse_constant_opcode with:
(const_vector:V4DI [
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0
--- Comment #15 from mkuvyrkov at gcc dot gnu dot org 2009-08-04 13:14
---
There are several (4, I think) patches posted in gcc-patches@ for this bug. A
reload/recog maintainer is needed to choose the most appropriate one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053
--- Comment #15 from paolo dot carlini at oracle dot com 2009-08-04 13:04
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Stat
--- Comment #14 from paolo at gcc dot gnu dot org 2009-08-04 13:01 ---
Subject: Bug 15523
Author: paolo
Date: Tue Aug 4 13:01:08 2009
New Revision: 150455
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150455
Log:
2009-08-04 Paolo Carlini
PR libstdc++/15523
--- Comment #5 from pault at gcc dot gnu dot org 2009-08-04 12:53 ---
Subject: Bug 40875
Author: pault
Date: Tue Aug 4 12:41:08 2009
New Revision: 150454
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150454
Log:
2009-08-04 Paul Thomas
PR fortran/40875
* dec
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-08-04 12:48
---
Testcase can be reduced to:
struct S
{
template
S (T const *)
{ }
template
S (char const (&)[N])
{ }
};
int
main()
{
S s1 ("test");
}
GCC still accepts this while Comeau rejects it.
--
jwak
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
|dot com
--- Comment #6 from dodji at gcc dot gnu dot org 2009-08-04 12:37 ---
Subject: Bug 39706
Author: dodji
Date: Tue Aug 4 12:28:27 2009
New Revision: 150453
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150453
Log:
2009-08-04 Dodji Seketeli
gcc/cp/ChangeLog:
PR debug/
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-08-04 12:35
---
I think you're right that this is a bug, this is a slightly reduced testcase
showing the same error:
template
struct make { static T&& it(); };
void (*pf)(int&) = 0;
template< typename T >
int bar(T const& x,
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.0 |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
--- Comment #5 from dodji at gcc dot gnu dot org 2009-08-04 12:31 ---
Fixed in 4.4 and 4.5. Waiting for 4.3 to unfreeze ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39706
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-08-04 12:30
---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-08-04 12:30
---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from rguenth at gcc dot gnu dot org 2009-08-04 12:30
---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-08-04 12:30 ---
GCC 4.3.4 is being released, adjusting target milestone.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 356 matches
Mail list logo
