--- Comment #6 from abel at gcc dot gnu dot org 2010-02-12 10:25 ---
I could take a look at this, but I cannot reproduce the ICE no matter how I
try, both with the full and reduced testcases, both with current trunk and the
one of Jan 29 (host x86-64, target
arm-oe-linux-uclibceabi/arm-u
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-12 10:43
---
Ok, so this is resolved as WONTFIX. Anyway, the PR remains in the database, of
course, and if somebody has ideas, partial solutions, whatever, those are of
course welcome, but let's not keep the PR in this lim
--- Comment #13 from gdr at integrable-solutions dot net 2010-02-12 11:06
---
Subject: Re: Strange behaviour of valarray::apply method
On Thu, Feb 11, 2010 at 6:22 PM, paolo dot carlini at oracle dot com
wrote:
> --- Comment #11 from paolo dot carlini at oracle dot com 2010-02-1
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-02-12 11:07 ---
This is because the Fortran frontend has different DECL_FUNCTION_CODE for the
same builtins as the middle-end, so they get mixed up (in this case LGAMMA
and GAMMA).
This needs to be fixed.
I also see
/* We defin
gfortran / gcc version 4.5.0 20100107 on OSX 10.6.2
This works if -fopenmp is _not_ used:
INTEGER*4 LISTEL(6,6,2000,200) ! 5760 bytes
COMMON/LKCELL/ LISTEL
It gives a runtime segmentation fault if -fopenmp is selected, even when there
are _no_ OMP directives in the code.
It works if the
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-12 12:40 ---
I cannot reproduce the problem with the array you have, but I can imagine one
problem with the real program.
By default, local variables of subroutines/functions are put into STATIC
memory; this no longer works if th
--- Comment #2 from dominiq at lps dot ens dot fr 2010-02-12 12:53 ---
As far as I know the "unlimited" stack size on Darwin cannot be larger than
64Mbytes. If you need/want more you need some special incantations:
-Wl,-stack_size,...
(see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=421
static void __attribute__((noinline))
foo (const char *x, long long y, int z)
{
asm volatile ("" : : "r" (x), "r" ((int) y), "r" (z) : "memory");
}
typedef struct S
{
struct S *n;
int v;
} *P;
P
bar (P c, int v, P e)
{
register int si asm ("esi"), di asm ("edi"), bx asm ("ebx");
asm vol
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051
--- Comment #8 from domob at gcc dot gnu dot org 2010-02-12 13:51 ---
I hit this bug, too, it seems. My reduced test-case:
PROGRAM analysis
IMPLICIT NONE
TYPE numlist
REAL, ALLOCATABLE :: nums(:)
END TYPE numlist
TYPE(numlist) :: lines
ALLOCATE (lines%nums(1))
CALL t
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-12 13:54 ---
(In reply to comment #2)
> /* We define these separately as the fortran versions have different
> semantics (they return an integer type) */
> gfc_define_builtin ("__builtin_roundl", mfunc_longdouble[0],
>
>
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-12 14:05 ---
Slightly smaller testcase:
static void __attribute__((noinline))
foo (const char *x, long long y)
{
asm volatile ("" : : "r" (x), "r" ((int) y), "r" (0) : "memory");
}
typedef struct S
{
struct S *n;
int v;
} *P
--- Comment #7 from Roger dot Jeurninck at home dot nl 2010-02-12 14:14
---
Created an attachment (id=19850)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19850&action=view)
test file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43036
--- Comment #8 from Roger dot Jeurninck at home dot nl 2010-02-12 14:15
---
I have attached a file on which I could reproduce the hang on:
- sparc-sun-solaris2.8 / GCC 4.4.2
- sparc-sun-solaris2.10 / GCC 4.4.2
- sparc-sun-solaris2.10 / GCC 4.4.3
- i486-linux-gnu / GCC 4.4.2
I hope you
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2010-02-12
14:40 ---
Does slackware provide packaging files to show how they build their gcc?
Normally all you need to do is download
ftp://sourceware.org/pub/java/ecj-latest.jar and place it as ecj.jar in the top
of the gcc s
memcmp-intensive code becomes up to 6 times slower if compiled with the -O3
option than with the -g or -O0 option. The reason for this is that the inline
memcmp function is *much* slower than the glibc memcmp.
Here's a simple test case:
#include
#include
#include
#include
void* list[1024 * 1
--- Comment #11 from spop at gcc dot gnu dot org 2010-02-12 14:54 ---
You need to upgrade your CLooG-PPL to 0.15.8 for this testcase to not fail.
I've put a comment in the testcase itself for this.
ftp://gcc.gnu.org/pub/gcc/infrastructure/cloog-ppl-0.15.8.tar.gz
Sebastian
--
spop
Compile this code (from the GDB testsuite) with G++ (tested 4.4.3, trunk):
class foo {
public:
int overload1arg (char);
};
int main ()
{
foo foo_instance1;
return 0;
}
int foo::overload1arg (char arg){ arg = 0; return 2;}
Here's the relevant bit of debug info:
<2><2d>:
--- Comment #1 from amonakov at gcc dot gnu dot org 2010-02-12 15:45
---
Confirmed. GCC simply emits repz cmpsb. There was even an e-mail with
benchmark results and a patch (never applied):
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02129.html
--
amonakov at gcc dot gnu dot org
--- Comment #1 from dodji at gcc dot gnu dot org 2010-02-12 15:48 ---
There are actually up to three destructors:
- an in-charge one (or complete-object one)
- a not-in-charge one
- a deleting in-charge one
The three of them are useful in different ways and in different circumstances.
--- Comment #2 from drow at gcc dot gnu dot org 2010-02-12 15:52 ---
The type of the class only contains one destructor. If you have to pick one
for a debugger to call, in-charge makes the most sense. For other debugger
purposes they all make equal sense (or nonsense).
If you want to
template struct future { };
#ifndef NO_PROTO
template
auto
async(Fn&& fn, Args&&... args)
-> future;
#endif
template
auto
async(Fn&& fn, Args&&... args)
-> future;
int work2(int value);
void work(int value)
{
auto handle = async(work2, value);
}
trunk gives this error:
$ g++45 -std=c++
--- Comment #6 from scott dot gccbugs dot 2009 at scottrix dot co dot uk
2010-02-12 16:16 ---
I get this on 4.4.3 for x86 32bit, is there a patch, or will I have to wait for
4.5 to be released ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37130
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-12 16:44 ---
So, when vt_find_locations visits the second time bb 4 in bar, it copies bb 4's
out set (just mentioning the important items):
name: c D.1235
offset 0
(value/s/u:SI 30:3972 @0x211f100/0x214cfa0)
(value/s/u
--- Comment #3 from jason at gcc dot gnu dot org 2010-02-12 17:00 ---
Your patch is correct; the default3.C failure is exposing a latent bug whereby
we fail to combine the default args from two templates, as we can see with this
testcase that fails without the patch:
template void g4(in
--- Comment #3 from jakub at gcc dot gnu dot org 2010-02-12 17:02 ---
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01016.html (without the IMHO wrong
swapping of the two traverses) doesn't help this case at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43051
--- Comment #11 from lucabon at interfree dot it 2010-02-12 17:18 ---
(In reply to comment #10)
> Does slackware provide packaging files to show how they build their gcc?
Yes, sure. It is a "standard" build, with ecj.jar placed in the top source
tree, and it is exactly the same build sc
--- Comment #3 from rknochenmuss at gmx dot net 2010-02-12 17:18 ---
Thanks guys. Apparently it is a stack limitation. Using ulimit -a, the default
is:
stack size (kbytes, -s) 8192
ulimit-s unlimited is not permitted. The largest value allowed is 2, this
isnt enough to avoid the seg
--- Comment #4 from jakub at gcc dot gnu dot org 2010-02-12 17:26 ---
Subject: Bug 43033
Author: jakub
Date: Fri Feb 12 17:26:12 2010
New Revision: 156734
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156734
Log:
PR c++/43033
* name-lookup.c (pushdecl_maybe_frie
--- Comment #5 from jakub at gcc dot gnu dot org 2010-02-12 17:27 ---
Subject: Bug 43033
Author: jakub
Date: Fri Feb 12 17:27:33 2010
New Revision: 156735
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156735
Log:
PR c++/43033
* name-lookup.c (pushdecl_maybe_frie
--- Comment #4 from davek at gcc dot gnu dot org 2010-02-12 17:35 ---
Subject: Bug 42982
Author: davek
Date: Fri Feb 12 17:35:18 2010
New Revision: 156736
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156736
Log:
2010-02-12 Dave Korn
Jack Howarth
Ia
Appear to be a recurrence of an older 'fixed' bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8260
I will attempt to compile the latest version gcj and see if the problem exists
there as well.
test.java
public class test {
public static void main(String[] args) {
--- Comment #1 from eldenc at tucsonembedded dot com 2010-02-12 18:17
---
Created an attachment (id=19851)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19851&action=view)
compiling this helloworld with 'gcj -fprofile-arcs -g --main=test test.java'
seg faults
--
http://gcc.gn
--- Comment #16 from jamborm at gcc dot gnu dot org 2010-02-12 18:29
---
Created an attachment (id=19852)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19852&action=view)
Patch making call statement redirection based on cgraph edges clearer
You may (or may not) be seeing an issue
--- Comment #4 from danny dot backx at scarlet dot be 2010-02-12 19:07
---
pavilion: {16} arm-wince-pe-gcc -v
Using built-in specs.
Target: arm-wince-pe
Configured with:
/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/gcc-4.4.0/configure
--with-gcc --with-gnu-ld --with-gnu-as --t
--- Comment #7 from raj dot khem at gmail dot com 2010-02-12 19:39 ---
you could try standalone target
../sources/gcc-trunk/configure --target=arm-none-eabi
--prefix=/scratch/oss/baremetal/arm-none-eabi/tools --enable-languages=c,c++
--with-newlib
and make sure that you pass -O0 -mthu
--- Comment #5 from danny dot backx at scarlet dot be 2010-02-12 19:44
---
Err, I used the wrong build tree with my last message.
This is the result with vanilla gcc-4.4.0 configured for arm-wince-pe :
different but still wrong.
Apologies for the fuckup.
pavilion: {37} arm-wince-pe-g
--- Comment #1 from jason at gcc dot gnu dot org 2010-02-12 19:46 ---
Subject: Bug 43054
Author: jason
Date: Fri Feb 12 19:46:29 2010
New Revision: 156737
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156737
Log:
PR c++/43054
* tree.c (cp_tree_equal): Correct CA
--- Comment #13 from jakub at gcc dot gnu dot org 2010-02-12 19:56 ---
default3.C g4 test has been XFAILed, for details see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43033#c3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15339
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-12 20:09 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from paolo dot carlini at oracle dot com 2010-02-12 20:15
---
Many thanks Jason.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43054
--- Comment #4 from rknochenmuss at gmx dot net 2010-02-12 20:22 ---
Removing the stack limitation is slightly more complicated than I reported
earlier:
I have found it is not only necessary to use the link option previously
suggested by Dominique, it may also be necessary to set this e
--- Comment #5 from janis at gcc dot gnu dot org 2010-02-12 20:35 ---
Created an attachment (id=19853)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19853&action=view)
minimized executable testcase
Compile with "-m64 -O2 -maltivec -ftree-vectorize -fdata-sections".
--
http://
--- Comment #6 from janis at gcc dot gnu dot org 2010-02-12 20:36 ---
In the attached testcase wrong code is generated for the loop in subroutine
sub3 that sets 12 of the elements of array k to zero. While minimizing the
testcase I saw different kinds of bad code for that array, but wit
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-12 20:49 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #20 from steven at gcc dot gnu dot org 2010-02-12 20:57 ---
What is the plan for this bug, fix it for GCC 4.5.0 or for later?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
--- Comment #18 from steven at gcc dot gnu dot org 2010-02-12 21:11 ---
As far as I'm concerned, this is WONTFIX for all affected compilers.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from steven at gcc dot gnu dot org 2010-02-12 21:37 ---
I'm not working on this => unassign.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from foom at fuhm dot net 2010-02-12 21:46 ---
Thanks, I will try doing that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290
--- Comment #14 from steven at gcc dot gnu dot org 2010-02-12 21:46 ---
On x86_64 the two functions still give different code:
;; Function strength_test2 (strength_test2)
strength_test2 (int * data)
{
unsigned int ivtmp.12;
int * pretmp.9;
int * pretmp.7;
int k;
int D.2743;
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-12 21:49 ---
Not worth pursuing, since RTL is only a tiny amount of memory these days (with
all GIMPLE function bodies and all DF info in memory also).
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from steven at gcc dot gnu dot org 2010-02-12 21:58 ---
GCC still doesn't get it right for this PR. The .139t.optimized dump for trunk
r156706:
;; Function foo (foo)
foo ()
{
int a.1;
int a.0;
:
a.0_1 = a;
a.1_2 = a.0_1 + 1;
a = a.1_2;
if (a.1_2 != 0)
g
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34503
--- Comment #10 from steven at gcc dot gnu dot org 2010-02-12 22:01 ---
Waiting for a m68k maintainer to do something here...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-12 22:02 ---
Waiting for a m68k maintainer to do something here...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19204
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-12 22:02 ---
Waiting for a m68k maintainer to do something here...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from steven at gcc dot gnu dot org 2010-02-12 22:03 ---
Waiting for a m68k maintainer to do something here...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-12 22:04 ---
No test case. No action.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2010-02-12 22:05 ---
No test case. No action.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19202
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-12 22:06 ---
.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-12 22:12 ---
The problem shows up at the tree level and nothing cleans it up after expand
for MIPS.
Take:
int
g (int n, int i)
{
int s = 0;
for (i = 0; i < n; i++)
s += i;
return s;
}
--- CUT ---
For the above code expa
--- Comment #4 from jason at gcc dot gnu dot org 2010-02-12 22:19 ---
This is basically the same bug as PR 41183.
We crash when trying to do name lookup during template substitution during
mangling during compilation of a clone. Cloning doesn't copy cfun->language, so
current_binding_le
--- Comment #5 from jason at gcc dot gnu dot org 2010-02-12 22:21 ---
Created an attachment (id=19854)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19854&action=view)
delta-reduced testcase
this testcase is a lot smaller, but still not as reduced as I'd like
--
http://gcc.gn
--- Comment #6 from jason at gcc dot gnu dot org 2010-02-12 22:27 ---
Subject: Bug 43024
Author: jason
Date: Fri Feb 12 22:27:04 2010
New Revision: 156740
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156740
Log:
PR c++/43024
* name-lookup.h (current_binding_lev
--- Comment #7 from jason at gcc dot gnu dot org 2010-02-12 22:27 ---
Subject: Bug 43024
Author: jason
Date: Fri Feb 12 22:27:14 2010
New Revision: 156741
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156741
Log:
PR c++/43024
* name-lookup.h (current_binding_lev
--- Comment #3 from steven at gcc dot gnu dot org 2010-02-12 22:27 ---
Basically yet another example of why it is a REALLY BAD IDEA to use constants
as PHI arguments. If the constant from "s =0" would not be propagated into the
PHI, the statement would not be dead and removed, and no new
--- Comment #30 from paolo at gcc dot gnu dot org 2010-02-12 22:31 ---
Subject: Bug 42819
Author: paolo
Date: Fri Feb 12 22:31:15 2010
New Revision: 156742
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156742
Log:
2010-02-12 Jonathan Wakely
Paolo Carlini
--- Comment #6 from jason at gcc dot gnu dot org 2010-02-12 22:32 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #31 from paolo dot carlini at oracle dot com 2010-02-12 22:34
---
Done.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #20 from steven at gcc dot gnu dot org 2010-02-12 22:46 ---
Bug 27016 is another example of poor IVOPTS due to poor choices in
arm_arm_address_cost
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from steven at gcc dot gnu dot org 2010-02-12 22:52 ---
If arm_arm_address_cost is "fixed" to return 1 unconditionally, the expected
code of comment #5 comes out at -Os, with the bonus of one less branch:
testme:
ldr r2, .L4
ldr r1, .L4+4
s
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-02-12 22:56 ---
But that is not the cause of the problem here. The issue comes down to we
simplify in 4.5 (subreg (sign_extend (reg N) ) ) into (reg N). fwprop1 is doing
that change on the trunk.
--
http://gcc.gnu.org/bugzilla
--- Comment #5 from steven at gcc dot gnu dot org 2010-02-12 23:08 ---
Can you explain how? It's not clear from the code of your comment #2 how a
simplification would cause the extra basic block.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839
--- Comment #8 from jakub at gcc dot gnu dot org 2010-02-12 23:09 ---
Created an attachment (id=19855)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19855&action=view)
ice16.ii
Slightly reduced testcase using some more delta, I'm afraid now needs some
manual work to help further r
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-02-12 23:14 ---
(In reply to comment #5)
> Can you explain how? It's not clear from the code of your comment #2 how a
> simplification would cause the extra basic block.
sorry if I was not clear here but there are two different iss
--- Comment #7 from pthaugen at gcc dot gnu dot org 2010-02-12 23:16
---
This looks like an ira/reload bug. The ira dump is where the offending insns
first show up.
(insn 17 26 244 3 pr42431.f:27 (set (mem:V4SI (reg/f:DI 29 29 [255]) [4 S16
A128])
(reg:V4SI 108 31 [269])) 942
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-02-12 23:35 ---
(In reply to comment #4)
> But that is not the cause of the problem here. The issue comes down to we
> simplify in 4.5 (subreg (sign_extend (reg N) ) ) into (reg N). fwprop1 is
> doing
> that change on the trunk.
--- Comment #21 from davek at gcc dot gnu dot org 2010-02-13 01:06 ---
(In reply to comment #20)
> What is the plan for this bug, fix it for GCC 4.5.0 or for later?
I don't really think I can argue that this is stage3 material, so the plan is
to fix it when trunk reopens for 4.6, and I
--- Comment #9 from paolo dot carlini at oracle dot com 2010-02-13 01:44
---
Actually, this is a feature, not a bug:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2913.pdf
--
paolo dot carlini at oracle dot com changed:
What|Removed
Your Email won you $1,00 in the Coca Cola online promo. To claim your prize
email your full name, address & tel. no. to Dr Shawn Kelly at
drshawnkel...@gmail.com or call +447011137303, +447031835069
Congratulations,
M. Sayeed
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2010-02-13
05:09 ---
The weak_import attribute is described fairly well in this technote
http://developer.apple.com/mac/library/technotes/tn2002/tn2064.html#SECTION2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4285
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-02-13
06:09 ---
On darwin, it would appear that the change in r155919 is unnecessary. Using...
--- /Users/howarth/gcc-4.5-20100211/gcc/varasm.c2010-01-20
18:46:25.0 -0500
+++ gcc/varasm.c2010-02-13
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-02-13 06:17
---
Created an attachment (id=19856)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19856&action=view)
Prelinary patch to fix this
The attached patch is preliminary. It borrows the existing gfc_trans_do code
an
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2010-02-13 06:39
---
I am reopening this bug. I stumbled upon it searching testcases from Manfred,
Running the test case here with 4.5 has not substantially improved. Time to
put on my thinking cap.
--
jvdelisle at gcc dot gnu
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-02-13 06:40
---
Assigning to myself.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
A
86 matches
Mail list logo
