--- Comment #3 from pault at gcc dot gnu dot org 2008-05-14 05:15 ---
(In reply to comment #2)
> OK to commit as simple.
>
Jerry,
In the clear light of day, I think that I need to separate the character and
the array checks. I'll check the standard and try other compilers - once I 'm
--- Comment #2 from spop at gcc dot gnu dot org 2008-05-14 03:59 ---
Subject: Re: redundant runtime check while vectorizing
How costly would it be if we do as a first data dependence test a call
to operand_equal_p on the array references? That certainly would
avoid lot of computations
--- Comment #3 from joseph at codesourcery dot com 2008-05-14 00:28 ---
Subject: Re: Duplicate PCH test names
On Tue, 13 May 2008, janis at gcc dot gnu dot org wrote:
> The PASS or FAIL messages come from a few levels deeper within the testsuite
> infrastructure, so dg-pch.exp can't j
--- Comment #2 from janis at gcc dot gnu dot org 2008-05-14 00:23 ---
Fixed by test changes from sje in r114327.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from janis at gcc dot gnu dot org 2008-05-14 00:21 ---
Fixed by sje in r114327 (fix below is for an unrelated PR).
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from janis at gcc dot gnu dot org 2008-05-14 00:17 ---
Are there any objections to calling this fixed, based on the committed patch
referenced in comment #2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26813
--- Comment #9 from janis at gcc dot gnu dot org 2008-05-14 00:12 ---
This has been fixed on active branches, OK to close it?
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-05-14 00:04
---
OK to commit as simple.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36233
--- Comment #2 from janis at gcc dot gnu dot org 2008-05-13 23:59 ---
This is still a problem.
The PASS or FAIL messages come from a few levels deeper within the testsuite
infrastructure, so dg-pch.exp can't just add something meaningful. It can,
however, change '$flags "-I."' to '"$fl
--- Comment #2 from kkojima at gcc dot gnu dot org 2008-05-13 22:43 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #11 from janis at gcc dot gnu dot org 2008-05-13 22:19 ---
Fixed, via documentation and workarounds.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from janis at gcc dot gnu dot org 2008-05-13 22:10 ---
Paulo, please send the patch from comment #2 to [EMAIL PROTECTED] with an
appropriate ChangeLog entry. Let me know if you need help with that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34880
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-13 22:08 ---
>ERROR: gcc.dg/var-expand3.c: error executing dg-final: no files matched glob
I reported this to the developer before:
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01229.html
--
pinskia at gcc dot gnu dot org ch
--- Comment #3 from janis at gcc dot gnu dot org 2008-05-13 22:03 ---
Fixed.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #6 from janis at gcc dot gnu dot org 2008-05-13 22:01 ---
Fixed.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from janis at gcc dot gnu dot org 2008-05-13 22:00 ---
Those tests have been failing for quite awhile and are reported through
http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg01958.html.
Starting in http://gcc.gnu.org/ml/gcc-testresults/2008-04/msg01978.html we see:
ERRO
--- Comment #1 from pault at gcc dot gnu dot org 2008-05-13 21:34 ---
(In reply to comment #0)
This fixs it and regtests OK
Index: gcc/fortran/interface.c
===
*** gcc/fortran/interface.c (revision 134835)
--- gcc/fortra
--- Comment #5 from uros at gcc dot gnu dot org 2008-05-13 21:34 ---
Subject: Bug 36222
Author: uros
Date: Tue May 13 21:33:40 2008
New Revision: 135275
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135275
Log:
PR target/36222
* config/i386/i386.c (ix86_expand_v
--- Comment #4 from janis at gcc dot gnu dot org 2008-05-13 21:34 ---
Fixed.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from janis at gcc dot gnu dot org 2008-05-13 21:29 ---
This was fixed by r135136; HJ's test results for that revision don't show the
failure.
--
janis at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from scottwood at freescale dot com 2008-05-13 21:13
---
(In reply to comment #4)
> If your code invokes undefined behavior, how is gcc going
> to read your mind?
If GCC can tell that it is undefined behavior, then warning the user is more
useful than silently producing
--- Comment #6 from nick dot spence at freescale dot com 2008-05-13 20:41
---
1) Since most bootloaders are written in C your view is very interesting but
probably not shared by everyone else working with embedded software.
2) If the compiler now treats this as an undefined condition i
module mod
contains
function foo (arg)
integer foo (10)
integer arg
foo = arg
end function
end module
use mod
call bar (foo)
contains
subroutine bar (arg)
interface
function arg (x)
integer arg (10)
integer x
end function
end interface
--- Comment #6 from pault at gcc dot gnu dot org 2008-05-13 20:28 ---
Fixed on trunk and 4.3
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pault at gcc dot gnu dot org 2008-05-13 20:27 ---
Subject: Bug 35997
Author: pault
Date: Tue May 13 20:26:47 2008
New Revision: 135273
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135273
Log:
2008-05-13 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/3
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-13 20:03 ---
Try 4.3.0 which includes fixes like this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-13 20:02 ---
>This section of code is used in a bootloader to test DRAM.
You cannot use C for that code because of how C defines pointers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36232
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-05-13 20:02
---
*** Bug 36232 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-13 20:02 ---
a pointer cannot go from a valid pointer to a NULL pointer. See PR 36124.
*** This bug has been marked as a duplicate of 36124 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from nick dot spence at freescale dot com 2008-05-13 19:56
---
The code has two loops, which compile correctly when no optimization, or
-O1 are used, but the second loop becomes infinite if -Os or -O2 is used.
.file "test.c"
.section.rodata.str1
--- Comment #5 from tromey at gcc dot gnu dot org 2008-05-13 19:52 ---
I don't see why this should be marked "wait".
Changing back to "new".
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from nick dot spence at freescale dot com 2008-05-13 19:52
---
Created an attachment (id=15637)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15637&action=view)
Compiler intermediate file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36232
--- Comment #1 from nick dot spence at freescale dot com 2008-05-13 19:51
---
Created an attachment (id=15636)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15636&action=view)
Example code source file
Compile with 'gcc -Os test.c' or 'gcc -O2 test.c' and examine assembly output.
This section of code is used in a bootloader to test DRAM.
It loops over the DRAM performing various operations of reads and writes.
When optimization (O2 or Os) is switched on the second loop in this example no
longer terminates, but continues indefinitely because the loop condition has
been rem
Include chain is ostream -> ios -> iosfwd -> bits/c++io.h -> bits/gthr.h ->
bits/gthr-default.h -> unistd.h. The same chain also includes pthread.h. These
are imported at file scope, not in namespace std, which pollutes the
application name space.
I tried to report this to libstdc++ project, but t
--- Comment #6 from jb at gcc dot gnu dot org 2008-05-13 19:07 ---
Patch for part 1 here:
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00769.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25561
--- Comment #4 from kargl at gcc dot gnu dot org 2008-05-13 18:11 ---
(In reply to comment #3)
> This is an important to fix. I just ran into problems from this. Gfortran is
> supposed to aim for standards conformance, but vendor extensions are not
> supposed to break valid code. I think
--- Comment #2 from janis at gcc dot gnu dot org 2008-05-13 18:07 ---
Subject: Bug 35127
Author: janis
Date: Tue May 13 18:06:33 2008
New Revision: 135269
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135269
Log:
PR testsuite/35127
* gcc.c-torture/compile/200311
--- Comment #3 from jkrahn at nc dot rr dot com 2008-05-13 17:05 ---
This is an important to fix. I just ran into problems from this. Gfortran is
supposed to aim for standards conformance, but vendor extensions are not
supposed to break valid code. I think this behavior is a Standards vi
--- Comment #2 from nemet at gcc dot gnu dot org 2008-05-13 16:38 ---
The change causing this was not present in 4.1.
--
nemet at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from dominiq at lps dot ens dot fr 2008-05-13 15:27 ---
I just noticed today that the vectorization of the variant induct.v2.f90
depends on the -m64 flag:
[ibook-dhum] source/dir_indu% gfc -m64 -O3 -ffast-math -funroll-loops
-ftree-vectorizer-verbose=2 indu.v2.f90
...
ind
--- Comment #18 from tromey at gcc dot gnu dot org 2008-05-13 15:20 ---
Fixed on trunk.
I think we're unlikely to backport this, so I'm closing it.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-05-13 15:01 ---
Ok, that doesn't really work well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36188
--- Comment #17 from tromey at gcc dot gnu dot org 2008-05-13 14:51 ---
Subject: Bug 22168
Author: tromey
Date: Tue May 13 14:50:27 2008
New Revision: 135264
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135264
Log:
libcpp
PR preprocessor/22168:
* include/cpplib
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-13 14:44 ---
Created an attachment (id=15635)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15635&action=view)
very optimistic patch
Which also handles
int f(int lay)
{
static int syncsize, init;
if (init == 1)
s
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-13 14:43 ---
So the problem is that we are not optimistically treating static variables. If
we fix that then the testcase is optimized to return 1344 with store_ccp. The
question is how many bugs we hit with that and how restri
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-05-13 14:13 ---
Only the theoretical problem remains. We still fold
(unsigned long)ptr + (unsigned long)i
to
(unsigned long)(ptr + (unsigned long)i)
where the inner POINTER_PLUS_EXPR now may invoke undefined behavior on
ove
--- Comment #4 from hjl dot tools at gmail dot com 2008-05-13 14:09 ---
It looks like reload doesn't check any vector instructions. I guess there may
be many missed optimizations with vector instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36222
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36227
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-13 14:05 ---
Subject: Bug 36227
Author: rguenth
Date: Tue May 13 14:04:40 2008
New Revision: 135261
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135261
Log:
2008-05-13 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-13 14:02 ---
Subject: Bug 36227
Author: rguenth
Date: Tue May 13 14:01:53 2008
New Revision: 135260
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135260
Log:
2008-05-13 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #3 from hjl dot tools at gmail dot com 2008-05-13 13:58 ---
This bug may be related to PR 30961. Another example:
bash-3.2$ cat d.c
#include
__m128i
foo2 (long long x1, long long x2)
{
return _mm_set_epi64x (x1, x2);
}
bash-3.2$ /export/build/gnu/gcc-stack/build-x86_64-l
--- Comment #3 from aaronavay62 at aaronwl dot com 2008-05-13 13:50 ---
Here is the information. I included the stage1 compiler as well just for
comparison purposes. For some reason, the source line information is missing
from both, but I suspect thats not very important.
Unfortunatel
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-13 13:40 ---
I belive this is a known issue with the data-dependence analyzer? (I never
understood why it doesn't recognize identical references...)
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from charlet at gcc dot gnu dot org 2008-05-13 13:40 ---
Assigning to myself.
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
Assign
--- Comment #8 from charlet at gcc dot gnu dot org 2008-05-13 13:39 ---
*** Bug 29127 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
--- Comment #11 from charlet at gcc dot gnu dot org 2008-05-13 13:39
---
Right, as I said, this is exactly PR864 for which I have an experimental
patch which needs small refinements.
Arno
*** This bug has been marked as a duplicate of 864 ***
--
charlet at gcc dot gnu dot org chan
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-13 13:38 ---
You are likely overrunning B.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rguenther at suse dot de 2008-05-13 13:36 ---
Subject: Re: gnatchop-gcc: installation problem, executable
not found
On Tue, 13 May 2008, charlet at gcc dot gnu dot org wrote:
> --- Comment #9 from charlet at gcc dot gnu dot org 2008-05-13 13:24
> ---
>
--- Comment #9 from charlet at gcc dot gnu dot org 2008-05-13 13:24 ---
I'm sorry, but I have an experimental patch (still needs some refining) fixing
PR864 which does also fix this PR, so I do not understand your comment, could
you
please elaborate ?
Arno
--
charlet at gcc dot gnu
--- Comment #21 from nightstrike at gmail dot com 2008-05-13 13:23 ---
ping.. Is there anyone that can help us with this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-13 13:16 ---
Created an attachment (id=15634)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15634&action=view)
patch fixing the problem
Regresses gcc.dg/tree-ssa/loadpre1[45].c, see PR36230.
--
http://gcc.gnu.org/bugz
If points-to sets for incoming pointers are properly pruned (see PR36201),
loadPRE no longer optimizes gcc.dg/tree-ssa/loadpre1[45].c which look like
# VUSE
d_3 = (*a_2(D))[0];
if (argc_4(D) != 0)
goto ;
else
goto ;
:
goto ;
:
:
# a_1 = PHI
# VUSE
e_6 = (*a_1)[0];
#include
#define length 50
int main()
{
int i=0,finish=0;
char A[length];
char B[3];
printf("Input A --> ? ");
scanf("%s",A);
printf("Input B --> ? ");
scanf("%s",B);
printf("Output A --> %s (It reads first char as \'\\0\')\n",A);
/* { dg-do compile } */
/* { dg-options "-O3 -c" } */
#define COLS 8
#define ROWS 8
int
t_run_test(void);
int
t_run_test()
{
int k_1,i_1, j_1;
static signed char f_1[ROWS][COLS] ;
static long F_1[ROWS][COLS] ;
long cosMatrixA[ROWS][COLS] ;
for( k_1 = 0 ;
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-13 12:54 ---
Part of the fix is
Index: fold-const.c
===
--- fold-const.c(revision 135255)
+++ fold-const.c(working copy)
@@ -6831,7 +6831,8 @@ fold_
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-13 12:43 ---
Err - only with volatiles ... !?
volatile unsigned long * sat_add(volatile unsigned long *ptr, unsigned long i,
volatile unsigned long *end)
{
if ((unsigned long)ptr + i * sizeof(*ptr) > (unsigned long)ptr)
re
--- Comment #16 from riccardo dot scorretti at univ-lyon1 dot fr
2008-05-13 12:42 ---
Hi! I think I'm experiencing a similar bug: the source code is:
program test_vecteurs
implicit none
integer :: n
integer, dimension(0:9) :: x = (/ (n, n=1,10,2), (0,n=1,5) /)
data (x(n), n=0
unsigned long * sat_add(unsigned long *ptr, unsigned long i, unsigned long
*end)
{
if ((unsigned long)ptr + i * sizeof(*ptr) > (unsigned long)ptr)
return ptr + i;
else
return end;
}
is folded to
if (ptr + (long unsigned int) (i * 8) > ptr)
{
return ptr + (long unsigned int
--- Comment #4 from siarhei dot siamashka at gmail dot com 2008-05-13
12:32 ---
This bug is still present in gcc 4.3
--
siarhei dot siamashka at gmail dot com changed:
What|Removed |Added
---
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-13 12:00 ---
Surely not, this would break the ABI.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from sam at gcc dot gnu dot org 2008-05-13 11:56 ---
Fixed in SVN trunk by Arno's patch.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from sam at gcc dot gnu dot org 2008-05-13 11:55 ---
Reopening to close it properly and setting target milestone.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-13 11:41 ---
The patch isn't really correct, but the problem is that the fact that
is marked addressable is causing flow-insensitive analysis to say that the
incoming pointers can alias it.
Also incoming pointers don't get usef
--- Comment #2 from oliver at linux-kernel dot at 2008-05-13 10:49 ---
Finally I have a working gcc 4.3.0, although I had to disable gnat compilation,
as there's some error. With gcc 4.3.0 ustr compiles, so this really is fixed.
Regarding gnat; Can we use this ticket for tracking the pr
--- Comment #14 from aurelien at aurel32 dot net 2008-05-13 10:34 ---
Created an attachment (id=15633)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15633&action=view)
Patch to fix the problem
This patch fixes the problem. It has been extracted from
gfortran-armel-updates.dpatch.
--- Comment #13 from aurelien at aurel32 dot net 2008-05-13 10:32 ---
> (The "Unshare RTX earlier..." one). Andrew and I actually did this work (ObjC
>
Good catch, I confirm that this part of the patch fixes the problem. This is
clearly a regression from gcc 4.2.
--
http://gcc.gnu.
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-05-13 09:39 ---
It's not the same. This is the problem that surfaces if you fix PR864.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-13 09:14 ---
Nevertheless, mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-05-13 09:07 ---
To fix potential TBAA miscompilations the vectorizer could mark all pointer
(types) it creates with TYPE_REF_CAN_ALIAS_ALL. But I guess I have a more
pragmatic fix for this.
--
rguenth at gcc dot gnu dot org cha
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2008-05-13 08:53
---
Fixed in the upcoming 4.3.1 release.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-05-13 08:52
---
Fixed in the upcoming 4.3.1 release.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-05-13 08:47
---
Subject: Bug 24880
Author: ebotcazou
Date: Tue May 13 08:46:49 2008
New Revision: 135258
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135258
Log:
PR ada/24880
PR ada/26635
* util
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2008-05-13 08:47
---
Subject: Bug 26635
Author: ebotcazou
Date: Tue May 13 08:46:49 2008
New Revision: 135258
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135258
Log:
PR ada/24880
PR ada/26635
* uti
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-05-13 08:47
---
Subject: Bug 24880
Author: ebotcazou
Date: Tue May 13 08:46:18 2008
New Revision: 135257
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135257
Log:
PR ada/24880
PR ada/26635
* util
--- Comment #12 from ebotcazou at gcc dot gnu dot org 2008-05-13 08:47
---
Subject: Bug 26635
Author: ebotcazou
Date: Tue May 13 08:46:18 2008
New Revision: 135257
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=135257
Log:
PR ada/24880
PR ada/26635
* uti
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-13 08:43 ---
Confirmed on 32bit targets.
SMT.6, UID D.1708, struct a, is addressable, is global, score: 320004, direct
reads: 0, direct writes: 0, indirect reads: 2, indirect writes: 0, call
clobbered (is global var, is incoming
--- Comment #6 from ludovic at ludovic-brenta dot org 2008-05-13 08:30
---
Also the bug should not remain tagged as INVALID.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31808
--- Comment #5 from ludovic at ludovic-brenta dot org 2008-05-13 08:29
---
Could someone please set the target milestone for this bug? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31808
90 matches
Mail list logo
