http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59523
--- Comment #2 from Igor Zamyatin ---
Created attachment 31454
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31454&action=edit
Reduced testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #21
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46371
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
Bug ID: 59535
Summary: [4.9 regression] -Os code size regressions for
Thumb1/Thumb2 (with LRA)?
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
--- Comment #1 from Richard Earnshaw ---
CSiBE code size results for Thumb2
2013/12/09 2543786
2013/12/11 2563522
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226
--- Comment #10 from Alexander Ivchenko ---
Patch from comment #7 didn't cure Android build as well..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226
--- Comment #11 from Markus Trippelsdorf ---
(In reply to Alexander Ivchenko from comment #10)
> Patch from comment #7 didn't cure Android build as well..
Can you try the patch from PR58252 comment 7?
I've build Chromium (browser) successfully w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58252
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471
--- Comment #4 from Jakub Jelinek ---
I think BIT_FIELD_REF's type can't be a vector, so it has to be integral type
in this case.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
--- Comment #2 from Richard Earnshaw ---
CSiBE code size results for Thumb1
2013/12/09 2634640
2013/12/11 2683980
=1.8% size regression.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59371
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #30 from Oleg Endo ---
A case from libmpeg2/slice.c:
mov.b @(1,r10),r0// load of shift amount
shldr7,r6
add #1,r6
extu.b r0,r0 // zero extend shift amount
shldr0,r1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
Richard Earnshaw changed:
What|Removed |Added
Summary|[4.9 regression] -Os code |[4.9 regression] -Os code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57189
--- Comment #5 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > Likely caused by r198611.
>
> This is the patch that exposes the problem.
>
> I have filled this PR due to the diff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
--- Comment #4 from Richard Earnshaw ---
Created attachment 31455
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31455&action=edit
testcase
Compile with -Os -mthumb -mcpu=arm7tdmi -fno-short-enums and either -mlra or
-mno-lra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59536
Bug ID: 59536
Summary: [4.9 regression] internal compiler error: in
cselib_record_set, at cselib.c:2376 breaks m68k-linux
bootstrap
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
--- Comment #5 from Richard Earnshaw ---
Number of register-register move operations in the testcase
lra:208
no-lra: 105
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57189
--- Comment #6 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Uroš Bizjak from comment #4)
> > (In reply to Jakub Jelinek from comment #3)
> > > Likely caused by r198611.
> >
> > This is the patch that exposes the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #21 from Markus Trippelsdorf ---
(In reply to Jan Hubicka from comment #20)
> Hmm, it may be someone altering the insns during streaming process. You may
> try to check
> who is doing that while streaming out the relevant .o file.
> I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53949
--- Comment #10 from Oleg Endo ---
I was wondering whether it would make sense to convert sequences such as
SH4 SH4A
mov.l @r15,r3 LS/2 LS/2
mul.l r2,r3CO/4 EX/3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53949
--- Comment #11 from Oleg Endo ---
Another question is whether the following is OK to do on all SH
implementations:
int test33 (int x, int y, int z)
{
return x * y + z;
}
currently compiles:
mul.l r5,r4
sts macl,r0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #22 from Oleg Endo ---
(In reply to Oleg Endo from comment #21)
> What happens is that the sequence is expanded to RTL as follows:
>
> (insn 7 4 8 2 (set (reg:SI 163 [ D.1856 ])
> (and:SI (reg/v:SI 162 [ xb ])
> (c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57422
Jakub Jelinek changed:
What|Removed |Added
CC||abel at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #22 from Markus Trippelsdorf ---
(In reply to Markus Trippelsdorf from comment #21)
>
> I've tried to bisect the issue, but it's messy.
> However I think I can rule out any commit since r205447.
> If r205447 is the culprit I cannot s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350
--- Comment #31 from David Binderman ---
Created attachment 31456
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31456&action=edit
C source code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350
--- Comment #32 from David Binderman ---
Same error with gcc trunk, dated 20131215, for attached
source code.
Flags -O3 -g -fPIC -fstack-protector-strong required.
[dcb@zippy4 foundBugs]$ ../results/bin/gcc -c -O3 -g -fPIC
-fstack-protector-stro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
--- Comment #6 from Richard Earnshaw ---
Created attachment 31457
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31457&action=edit
Another testcase
Another testcase, but this one has some obvious examples of poor behaviour for
-Os.
In addti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305
--- Comment #7 from Dominique d'Humieres ---
Created attachment 31458
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31458&action=edit
reduced test case
c11-atomic-exec_5.c reduced to the test of complex_long_double_add_overflow
only. It tak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305
--- Comment #8 from Dominique d'Humieres ---
Created attachment 31459
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31459&action=edit
test without the complex instances
The running time fluctuates between 1.6 and 7.5s on an unloaded machine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55500
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59523
H.J. Lu changed:
What|Removed |Added
Status|WAITING |NEW
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59527
--- Comment #3 from Teresa Johnson ---
On Mon, Dec 16, 2013 at 10:41 AM, Teresa Johnson wrote:
> I will take a look and report back. -freorder-blocks-and-partition was
> recently enabled by default, which presumably exposed this issue.
The issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59534
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59486
H.J. Lu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272
--- Comment #22 from rguenther at suse dot de ---
On 12/17/13 9:29 AM, amker.cheng at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52272
>
> bin.cheng changed:
>
>What|Removed |Added
> -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59486
H.J. Lu changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55498
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Summa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59534
--- Comment #10 from Jakub Jelinek ---
Author: jakub
Date: Tue Dec 17 15:17:00 2013
New Revision: 206051
URL: http://gcc.gnu.org/viewcvs?rev=206051&root=gcc&view=rev
Log:
PR testsuite/59534
* testsuite/libgomp.fortran/retval1.f90 (e5): Av
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59523
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59523
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54957
Kai Tietz changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59350
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35913
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41823
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42478
Bug 42478 depends on bug 41823, which changed state.
Bug 41823 Summary: gcc/fortran/trans-openmp.c: possible null pointer dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41823
What|Removed |Added
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51610
Dominique d'Humieres changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #5 from Dominique
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47316
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47316
--- Comment #5 from Jan Hubicka ---
The testcase provided now generates:
void foo(A*) (struct A * a)
{
int (*__vtbl_ptr_type) () * _3;
int (*__vtbl_ptr_type) () _4;
int i.0_6;
int i.1_7;
void * PROF_9;
int i.2_11;
int i.3_12;
:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47462
Jan Hubicka changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55150
Ryan Mansfield changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226
--- Comment #12 from Alexander Ivchenko ---
(In reply to Markus Trippelsdorf from comment #11)
> (In reply to Alexander Ivchenko from comment #10)
> > Patch from comment #7 didn't cure Android build as well..
>
> Can you try the patch from PR5825
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45631
Jan Hubicka changed:
What|Removed |Added
CC||davidxl at google dot com
--- Comment #5 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59511
--- Comment #3 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #2)
> One movdqa started appearing with r204212, the second movdqa started
> appearing with r204752. Vlad, can you please have a look?
It seems the changes triggere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42949
Ryan Mansfield changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45511
Ryan Mansfield changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45814
Ryan Mansfield changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59233
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49521
Ryan Mansfield changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43588
Ryan Mansfield changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45885
Ryan Mansfield changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59147
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59233
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59466
Vladimir Makarov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59147
--- Comment #5 from rglindley at gmail dot com ---
(In reply to Kai Tietz from comment #4)
> I've tested testcase on x86_64-w64-mingw32 cross-compiler, and I can't
> reproduce issue with current trunk.
> As 4.6.1 isn't supported anymore upstream, c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45631
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #6 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58290
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Tue Dec 17 17:35:59 2013
New Revision: 206062
URL: http://gcc.gnu.org/viewcvs?rev=206062&root=gcc&view=rev
Log:
PR ipa/58290
* gfortran.dg/pr58290.f90: New test.
Added:
trunk/
rtran --version
GNU Fortran (GCC) 4.9.0 20131217 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58290
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #3 from Jan Hubicka ---
Following patch gets rid of OBJ_TYPE_REF
Index: value-prof.c
===
--- value-prof.c(revision 206040)
+++ value-prof.c(working copy)
@
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58290
--- Comment #8 from Joost VandeVondele
---
(In reply to Jakub Jelinek from comment #7)
> I've looked at this some more and it seems Richard's change was the right
> fix for this, so I've committed the testcase and am closing this.
Thanks. I noti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58290
--- Comment #9 from Jakub Jelinek ---
This is actually the same testcase, just somewhat manually reduced and with
symbol names simplified.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #4 from rguenther at suse dot de ---
"hubicka at gcc dot gnu.org" wrote:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
>
>Jan Hubicka changed:
>
> What|Removed |Added
>--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #5 from Jan Hubicka ---
Main issue seems to be that VRP messes up on:
# ap_2 = PHI
# prephitmp_14 = PHI <&MEM[(void *)&_ZTV1A + 16B](5)>
_19 = *prephitmp_14;
here it somehow won't constant propagate the load.
Index: passes.def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59085
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #3 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471
--- Comment #5 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #4)
> I think BIT_FIELD_REF's type can't be a vector,
Er, I am quite sure a BIT_FIELD_REF can be a vector. Maybe that wasn't a
general statement and I missed the context?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471
--- Comment #6 from Jakub Jelinek ---
You mean BIT_FIELD_REF argument can be a vector? Sure. But the type of the
BIT_FIELD_REF itself?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #6 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58668
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59533
--- Comment #3 from Oleg Endo ---
This is basically the same issue as PR 54685.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59519
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #7 from Jan Hubicka ---
> You certainly don't want to put something between DOM and phi-only-cprop.
> Jump
> threading will tend to expose lots of degenerate PHIs. phi-only-cprop
> eliminates those degenerates. We could have used t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54685
--- Comment #9 from Oleg Endo ---
This is basically the same issue as PR 59533. emit_store_flag_1 in expmed.c
always expands the not-shift because the assumption there is that it's cheaper,
which is not true for SH.
The pre-peephole idea from ht
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58668
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59431
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P5
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59538
Bug ID: 59538
Summary: Optimization of -O2 or higher creates incorrect code
in loop
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58701
Marek Polacek changed:
What|Removed |Added
Priority|P1 |P2
--- Comment #5 from Marek Polacek ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59265
--- Comment #23 from Markus Trippelsdorf ---
Here's a testcase:
tmp % wget trippelsdorf.de/cceI2Nud.ltrans22.o.bz2
tmp % bzip2 -d cceI2Nud.ltrans22.o.bz2
tmp % g++ -xlto -fltrans cceI2Nud.ltrans22.o
In member function ‘extractBetween’:
lto1: f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59147
Kai Tietz changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #10 from Jan Hubicka ---
> Tracer depends on the usual estimate_num_insns limits
> (it is 12 years since I wrote it, so what I recall)
note that one impotant thing that changed in those 12 years is that I
originally carefuly tuned tr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #9 from Jan Hubicka ---
> It's not a matter of cost model, but if propagating the values to their uses.
> I haven't looked closely at the tracer, but wouldn't it benefit by having
> constants in particular propagated to their uses?
T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59433
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P5
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39578
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59471
--- Comment #7 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #6)
> You mean BIT_FIELD_REF argument can be a vector? Sure. But the type of the
> BIT_FIELD_REF itself?
Yes, the type of the BIT_FIELD_REF itself. A quick grep gives:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P5
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59430
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P5
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59538
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #8 from Jeffrey A. Law ---
It's not a matter of cost model, but if propagating the values to their uses.
I haven't looked closely at the tracer, but wouldn't it benefit by having
constants in particular propagated to their uses?
Yes,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58115
Bernd Edlinger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
1 - 100 of 135 matches
Mail list logo
