at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #11 from Thomas Koenig ---
Harald, thanks for reducing it!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99199
Thomas Koenig changed:
What|Removed |Added
Version|unknown |11.0
Target Milestone|---
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Created attachment 50233
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50233&acti
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following is currently rejected:
program main
use, intrinsic :: iso_fortran_env
type (team_type) :: odd_even
integer :: me
||tkoenig at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
--- Comment #4 from Thomas Koenig ---
Seems fixed... I'll try to commit the test case this evening.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93524
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
|--- |FIXED
CC||tkoenig at gcc dot gnu.org
--- Comment #2 from Thomas Koenig ---
Works now, fixed by I don't know what commit.
Test case committed as
https://gcc.gnu.org/g:80198c701a7fc09e736ccffe470ee5033ca59a69 , closing.
Thanks fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94408
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924
Thomas Koenig changed:
What|Removed |Added
Summary|[OOP] segfault with |[OOP] ICE with procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924
--- Comment #6 from Thomas Koenig ---
This actually segfaults at runtime.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924
Thomas Koenig changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
Bug 20585 depends on bug 93925, which changed state.
Bug 93925 Summary: Invalid memory reference upon call of a routine taking a
procedure pointer as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
||tkoenig at gcc dot gnu.org
--- Comment #3 from Thomas Koenig ---
I just ran this through nagfor, and it agrees with gfortran.
Nagfor is usually quite picky.
xlf, on the other hand, agrees with you, so it does not seem
to be straightforward, at least.
This will take some further
||tkoenig at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #2 from Thomas Koenig ---
The code has been fixed in the meantime. I have committed the
test case as r11-6899-g7d54cccad332074d5fb81123796239f0f61b11a7
to make sure there is no
||tkoenig at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from Thomas Koenig ---
The test case works, I have committed it as
https://gcc.gnu.org/pipermail/gcc-cvs/2021-January/341018.html
to make sure it does not regress.
Thanks for the
||tkoenig at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #7 from Thomas Koenig ---
I think the documentation for this is adequate:
1.3 Preprocessing and conditional compilation
=
Many Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345
Thomas Koenig changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48786
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
Bug 68241 depends on bug 66910, which changed state.
Bug 66910 Summary: allocatable character in derived type gives segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66910
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66910
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98701
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
--- Comment #4 from Thomas Koenig ---
Yes, I think that translating a DO loop into something like
int i;
for (i=0; i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82480
--- Comment #4 from Thomas Koenig ---
(In reply to Janne Blomqvist from comment #3)
> Actually, libgfortran already has a version of stat with integer(kind=int64)
> arguments. If you compile with -fdefault-integer-8 you get that one, and the
> ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
--- Comment #2 from Thomas Koenig ---
(In reply to Tobias Schlüter from comment #1)
> There's a typo in the example, /= instead of !=. Fixed example below:
The disease of a Fortran programmer writing C, I guess :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552
Thomas Koenig changed:
What|Removed |Added
Version|unknown |11.0
Keywords|
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Consider
void foo (int *);
void bar (int n)
{
int i;
for (i=0; i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438
--- Comment #3 from Thomas Koenig ---
Could you simply post the complete C++ source code that you used
in the original example? This has the advantages of a) making it easier
to modify (for a non-C++-person such as me) and b) of conforming
to the
||tkoenig at gcc dot gnu.org
--- Comment #3 from Thomas Koenig ---
At least something that works on the shared coarray branch :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98438
Thomas Koenig changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756
Thomas Koenig changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91648
Thomas Koenig changed:
What|Removed |Added
Blocks||37336
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93114
--- Comment #3 from Thomas Koenig ---
Probably a better idea:
If the span can be shown at compile-time to be a multiple of
the size of the component, we need not create the temporaray array
and instead set the strides of the descriptor according
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Consider
program main
character (len=:), allocatable :: a(:)
allocate (character(len=10) :: a(5))
end program main
This yields (in the tree dump)
D.3941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065
--- Comment #13 from Thomas Koenig ---
(In reply to Gabor from comment #10)
> Good to know that gfortran has come to an end. It means, for example, that
> i will not rely on the openacc implementation either. Or openmp5.
Those two fields are act
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97304
--- Comment #8 from Thomas Koenig ---
(In reply to Andreas Tobler from comment #7)
> Any news on this? Or can we close this PR?
Neither. As far as I can determine, this still fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86551
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90207
--- Comment #5 from Thomas Koenig ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561720.html
allows debugging of the generated variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97920
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
--- Comment #10 from Thomas Koenig ---
I don't have a working mingw system myself, but I dusted off my cygwin
system for this, using their cross-compiler to mingw.
With
$ x86_64-w64-mingw32-gfortran.exe -static -static-libgfortran csqrt.f90
th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
--- Comment #8 from Thomas Koenig ---
(In reply to dpozar from comment #6)
> Thomas,
> I am running that code in code blocks with MS visual C++ 2010, but I can't
> find the output - no console screen, and no output file that I can find.
What if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
--- Comment #5 from Thomas Koenig ---
What is the output of
#include
#include
int main()
{
_Complex float z, sq, sq2;
int n;
float a;
a = -1.;
for (n = 1; n < 10; n++)
{
a = a * 10;
z = a + _Complex_I * 1.0;
sq
||tkoenig at gcc dot gnu.org
--- Comment #1 from Thomas Koenig ---
Here is a slight extension of your program, which also
checks the compile-time simplification. Can you tell me
what it does?
program main
implicit none
integer :: i,n
complex z, sq
complex, parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
Bug 83700 depends on bug 98156, which changed state.
Bug 98156 Summary: [Coarray] alloc_comp_1.f90 tests for wrong condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98156
What|Removed |Added
---
gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Thomas Koenig ---
Fixed by
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=bd0f0243869b3941a256ca0ea9c8aca141412f7e
Closing.
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
alloc_comp_1.f90 has
! { dg-do run }
!
! Allocatable scalar corrays were mishandled (ICE)
!
type t
integer, allocatable :: caf[:]
end type t
type(t) :: a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #10 from Thomas Koenig ---
(In reply to anlauf from comment #9)
> The patch seems to regtest ok, but certainly needs some wider testing.
Actually, I think the bug is in io/unix.c:raw_read. That should take
care of repeating the reads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
Thomas Koenig changed:
What|Removed |Added
Target||x86_64-pc-linux-gnu
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #3 from Thomas Koenig ---
The problem seems to be that we assume that a short read is always
an EOF, in read_block_direct:
if (unlikely ((ssize_t) nbytes != have_read_record))
{
/* Short read, e.g. if we hit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129
--- Comment #2 from Thomas Koenig ---
The problem seems to be related to an early return from the read system call:
strace -e trace=open,read,close ./a.out
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\v\2\0\0\0\0\0"...,
832) = 832
c
: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The following program
program main
implicit none
integer, parameter :: n = 10**7
integer :: u,v
integer, dimension(:), allocatable :: a
open (newunit=u,file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #26 from Thomas Koenig ---
Yep, it's implemented and works great.
For a simple "sum of digits" program in base ten, it's an acceleration
by more than a factor of two.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95293
--- Comment #11 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #10)
> Could this PR be closed as INVALID?
Yes, I think so.
|1
Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot
gnu.org
Severity|normal |enhancement
Target Milestone|--- |11.0
Last reconfirmed||2020-12-01
Status
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Currently, we use GFC_INTEGER_LARGEST for a lot of integer I/O.
One place where things could be improved is gfc_itoa:
const char *
gfc_itoa (GFC_INTEGER_LARGEST n, char *buffer
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
There is dg-set-target-env-var , which we could use to check that
the runtime behavior which depends on environment variables is
indeed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26183
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #26 from Thomas Koenig ---
After 00c2e5d1c15c67fc2c9d9ed86bfa1f5aa13848cc ,
the segfault for too many images is now also fixed,
and your program runs as expected.
I'd say an important milestone has been reached :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #22 from Thomas Koenig ---
Hi Toon,
it took some time, but we finally figured out that it is actually
a bug in your program that is causing problems.
It has (shortened)
nxglobal = 72;
This sets the coarray nxglobal to 72 on every
|1
Status|UNCONFIRMED |WAITING
CC||tkoenig at gcc dot gnu.org
--- Comment #1 from Thomas Koenig ---
Seems to be fixed on current trunk:
$ cat bug.f90
program p
real :: y(3)
n=3
y = func(0.)
stop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #21 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #18 from Thomas Koen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #17 from Thomas Koenig ---
A bit more reduced (no derived types necessary):
program random_weather
implicit none
real, allocatable :: ps(:,:) [:,:]
integer :: nxslab, nyslab
integer :: npx
integer :: i, j
real, paramete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #16 from Thomas Koenig ---
program random_weather
implicit none
type global_model_state
real, allocatable :: ps(:,:) [:,:]
end type global_model_state
integer :: nxslab, nyslab
type(global_model_state) :: ms_full
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #15 from Thomas Koenig ---
Next reduced test-case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #14 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #13)
> (In reply to Thomas Koenig from comment #12)
> > Reduced test case:
> >
> > program main
> > type global_model_state
> > real, allocatable :: ps(:) [:]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #13 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #12)
> Reduced test case:
>
> program main
> type global_model_state
> real, allocatable :: ps(:) [:]
> end type global_model_state
> type (global_model_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #12 from Thomas Koenig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #10 from Thomas Koen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97799
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |10.3
Summary|Passing CHARACTE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97799
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97799
--- Comment #9 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #8)
> Comment on attachment 49548 [details]
> bugtest.f -- program evincing bug
>
> So, commit the test case to guard against regressions
> (since it is not immediatel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97799
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38592
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2017-08-15 00:00:00 |2020-11-11
--- Comment #10 from Thomas K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30398
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21046
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2014-12-25 00:00:00 |2020-11-11
--- Comment #6 from Thomas Ko
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97770
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Thomas Koeni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|REOPENED|NEW
--- Comment #5 from Thomas Koenig -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #4 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #3)
> Simplified test case:
>
> program main
> type foo
> real, allocatable, dimension(:) :: a[:]
> end type foo
> type (foo) :: x
> sync all
> allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97756
--- Comment #1 from Thomas Koenig ---
Actually, it was on a Ryzen 1700 (for the -march=native).
I'm at odds with architecture names...
|normal |enhancement
CC||tkoenig at gcc dot gnu.org
--- Comment #1 from Thomas Koenig ---
Could you post the benchmark and the exact architecture where the arithmetic
version is faster?
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
This is an offshoot from PR 97459.
The code
#define ONE ((__uint128_t) 1)
#define TWO_64 (ONE << 64)
#define MASK60 ((1ul << 60) - 1)
typedef __uint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #17 from Thomas Koenig ---
To be compilable, my previous code lacks
typedef __uint128_t mytype;
> #define ONE ((__uint128_t) 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #16 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #15)
> I plan to work on this early in stage3.
> And we really shouldn't use any tables, GCC should figure it all out.
> So, for double-word modulo by constant that wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
--- Comment #3 from Thomas Koenig ---
Simplified test case:
program main
type foo
real, allocatable, dimension(:) :: a[:]
end type foo
type (foo) :: x
sync all
allocate (x%a(10)[*])
end program main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #14 from Thomas Koenig ---
Created attachment 49520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49520&action=edit
Numbers a, b so that 2^b ≡ 1 mod a up to b=64, larger b taken if several
solutions exist, plus the multiplicat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97738
--- Comment #5 from Thomas Koenig ---
(In reply to Jakub Jelinek from comment #4)
> What about a version that still sets lowest_bit to value & -value; rather
> than 1 < ctz?
I think this would be ideal, or close to it.
> Also, I'm not sure you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97738
--- Comment #3 from Thomas Koenig ---
Even faster code:
ctz = __builtin_ctz (value);
lowest_bit = value & - value;
left_bits = value + lowest_bit;
changed_bits = value ^ left_bits;
right_bits = changed_bits >> (ctz + 2);
return left_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97738
--- Comment #2 from Thomas Koenig ---
Created attachment 49516
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49516&action=edit
Small benchmark
Here's a small benchmark for counting all 32-bit numbers with 16 bits set
according to the HAKM
: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
A straightforward implementation of HAKMEM 175 (returning
the next number with the same number of bits) is
unsigned int
next_same_bit (unsigned int v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96735
Thomas Koenig changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
This involves Fortran, but possibly also other languages.
Consider
$ cat alias.f90
program main
interface
subroutine foo(a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97589
Thomas Koenig changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
201 - 300 of 3591 matches
Mail list logo
