https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71493
--- Comment #5 from Michael Meissner ---
Author: meissner
Date: Tue Jul 19 03:31:48 2016
New Revision: 238454
URL: https://gcc.gnu.org/viewcvs?rev=238454&root=gcc&view=rev
Log:
[gcc]
2016-07-18 Michael Meissner
PR target/71493
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71493
--- Comment #6 from Michael Meissner ---
Author: meissner
Date: Tue Jul 19 03:39:34 2016
New Revision: 238455
URL: https://gcc.gnu.org/viewcvs?rev=238455&root=gcc&view=rev
Log:
[gcc]
2016-07-18 Michael Meissner
Back port from mainlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71493
Michael Meissner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71869
--- Comment #2 from Michael Meissner ---
Author: meissner
Date: Wed Jul 27 04:45:59 2016
New Revision: 238779
URL: https://gcc.gnu.org/viewcvs?rev=238779&root=gcc&view=rev
Log:
[gcc]
2016-07-26 Michael Meissner
PR target/71869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847
--- Comment #15 from Michael Meissner ---
Thanks for doing this. It looks like Bill will do spec testing, but if he
doesn't I will fire off a run early next week.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71869
--- Comment #3 from Michael Meissner ---
Author: meissner
Date: Thu Aug 4 21:25:05 2016
New Revision: 239154
URL: https://gcc.gnu.org/viewcvs?rev=239154&root=gcc&view=rev
Log:
[gcc]
2016-08-04 Michael Meissner
Backport from trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71869
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72771
Michael Meissner changed:
What|Removed |Added
Target Milestone|6.2 |7.0
--- Comment #3 from Michael Meiss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72853
--- Comment #1 from Michael Meissner ---
I believe this is a duplicate of PR 72802 that Alan fixed on August 8th for
trunk (subversion id 239233), and backported to the gcc-6-branch (subversion id
239269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72853
--- Comment #2 from Michael Meissner ---
Created attachment 39090
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39090&action=edit
Proposed patch to fix the problem
Alan mixed up the stxsspx and stxssp alternatives. I haven't yet done the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72853
Michael Meissner changed:
What|Removed |Added
Attachment #39090|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72853
--- Comment #6 from Michael Meissner ---
Author: meissner
Date: Wed Aug 10 13:49:12 2016
New Revision: 239325
URL: https://gcc.gnu.org/viewcvs?rev=239325&root=gcc&view=rev
Log:
[gcc]
2016-08-10 Michael Meissner
PR target/72853
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72853
--- Comment #7 from Michael Meissner ---
Author: meissner
Date: Wed Aug 10 18:15:37 2016
New Revision: 239331
URL: https://gcc.gnu.org/viewcvs?rev=239331&root=gcc&view=rev
Log:
Backport from mainline:
[gcc]
2016-08-10 Michael Meissner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72853
Michael Meissner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #20 from Michael Meissner ---
Yeah, it sounds like you don't want to adjust any of the stack related
registers.
However, in looking at this $#!%, we probably need to rewrite it so it doesn't
do clever tricks like this. Which probabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #22 from Michael Meissner ---
Note, if the index register is R0 and the base register is SP, you might not be
able to use the other register (well you can use it, but you likely will get a
segmentation fault or just access the wrong m
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
I noticed that the insn that supports the PowerPC xxeval instruction uses the
predicate "altivec_register_operand". It should use the predicate
"vsx_regist
||2021-04-09
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
I noticed there are a bunch of the fold-vec-load* and fold-vec-store* tests
that fail if you
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
If you configure GCC using --with-cpu=power10, the fold-vec-div-longlong.c
fails. This is due to the test
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
The test gcc.dg/pr56727-2.c fails if you build a compiler with default power10
code generation (--with-cpu=power10). The test fails
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
I was doing a comparison between tests between a compiler configured for
power10 and one configure for power9. The test gcc.dg/sms-10.c fails on
power10. The SMS pass fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100166
--- Comment #1 from Michael Meissner ---
The test gcc.dg/vect/costmodel/ppc/costmodel-bb-slp-9a-pr63175.c also fails
because it needs to add prefixed instruction support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100166
--- Comment #2 from Michael Meissner ---
gcc.target/powerpc/lvsl-lvsr.c is another test that needs prefixed load/store
support added.
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
If you configure a compiler where the default code generation is power10, the
tests ppc-ne0-1.c and ppc-eq0-1.c fail. The reason is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
--- Comment #5 from Michael Meissner ---
One of my patches for adding IEEE 128-bit long double may help with this
situation. The ibm-ldouble.c module was not being compiled with
-mno-gnu-attributes would affect things if a different long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
--- Comment #7 from Michael Meissner ---
Just to be clear, my patch only turns on -mno-gnu-attributes on compiling
ibm-ldouble.c. That is the module that has the extended IBM 128-bit support in
it.
However, I believe if any module in libgcc_s.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
--- Comment #8 from Michael Meissner ---
In addition to ibm-ldouble.c, the following functions set the gnu attribute #4
to 5 (i.e. pass/use IBM extended double as long double):
_divtc3
_fixtfdi
_fixunstfdi
_floatditf
_floatunditf
_multc3
_powitf
|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #4 from Michael Meissner ---
You need the patch that fixes PR libgcc/97543, which is another side of the
same coin. PR 97543 was about making long double default to 64-bits, PR 97643
is about making long double default to IEEE 128-bi
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
The long double gnu attributes on PowerPC are not quite correct.
If you have a function that returns __float128 when the ABI is IBM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96791
--- Comment #22 from Michael Meissner ---
When I wrote the original in power7 days, the intent was:
If the user said -mcpu=power7 (for 32-bit) and did not explicitly set either
-mabi=altivec or -mabi=no-altivec, that -mabi=altivec would be set
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #2 from Michael Meissner ---
That fell off the plate. I imagine we are going to need a hook with asm that
makes sure none of the memory references are PC-relative.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #9 from Michael Meissner ---
I agree with Segher. Given the 'magic' we need to add the missing 'p' and set
the length for normal RTL, I don't see any reasonable way to add it to asm. We
will just need to use a hook (or make one) to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #15 from Michael Meissner ---
FWIW, the hook that will need to be modified is rs6000_md_asm_adjust in
rs6000.c. It appears you are passed the outputs, the inputs, the constraints,
and the clobbers. Right now, we just mark the CA reg
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
I am tuning up the final patches for providing support to enable the PowerPC
server compilers to change the default long double
,
||dje at gcc dot gnu.org,
||meissner at gcc dot gnu.org,
||nathan at gcc dot gnu.org,
||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Bug 97653 depends on bug 97543, which changed state.
Bug 97543 Summary: powerpc64le: libgcc has unexpected long double in
.gnu_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Michael Meissner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
In checking in the change on January 28th that changes the built-in function
names if long double is IEEE
gcc dot gnu.org,
||dje at gcc dot gnu.org,
||meissner at gcc dot gnu.org,
||segher at gcc dot gnu.org,
||seurer at
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
In looking at PR target/98870, I noticed that there is a failure of another
module (gcc.target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98870
Michael Meissner changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #21 from Michael Meissner ---
I have patches that fix the problem in the hook.
My original idea of not allowing prefixed insns in the hook doesn't work
because when the hook is called, it only sees pseudo registers.
So what my patch
|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
gcc dot gnu.org|unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #23 from Michael Meissner ---
Obviously one approach is to use the recog_data.is_asm field to determine if
the %m constraint is in an asm and restrict it to non-prefixed memory
addresses.
However, this doesn't work, because is_asm is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #24 from Michael Meissner ---
Obviously I had a small typo in the previous example (using %U0%X0 instead of
%U1%X1) which did not matter, but here is the corrected example:
static int x;
int *p_x = &x;
int get (void)
{
int a;
__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #25 from Michael Meissner ---
Created attachment 50201
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50201&action=edit
Example code for both input and output %m usage
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
The power10 instructions added for loading up constants in the vector registers
(xxspltib, xxspltidp, xxsplti32dx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99133
--- Comment #1 from Michael Meissner ---
Note, the comment should read:
Note unlike the load/store/paddi instructions, these prefixed instructions do
NOT have a 'p' prefix, which means the code in rs6000_final_prescan_insn will
have to be modifie
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
Last reconfirmed||2021-02-17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98952
Michael Meissner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100327
Michael Meissner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100327
--- Comment #5 from Michael Meissner ---
Unfortunately the patch does not work because there aren't suffixes for IFmode
and KFmode.
||
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2021-04-29
Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
--- Comment #6 from Michael
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100327
Michael Meissner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
||2021-05-04
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
--- Comment #3 from Michael Meissner ---
I have patches for most of the cases, but I will be out for ~2 weeks. If
somebody wants
|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Michael Meissner ---
I have patches for this and I will submit it when I get back from surgery. If
somebody
|ASSIGNED
Last reconfirmed||2021-05-04
Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
--- Comment #1 from Michael Meissner ---
Note, gcc.target/powerpc/fold-vec-mult-longlong.c has a similar issue.
I have patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100170
Michael Meissner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
The vec_splatid builtin from altivec.h (i.e. __builtin_vec_xxspltid
|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||meissner at gcc dot gnu.org
--- Comment #1 from Michael Meissner ---
The example only shows the bug with big endian, 32-bit without optimization.
If you optimize the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96762
--- Comment #2 from Michael Meissner ---
It is in the memcpy expansion, when the compiler tries to generate lxvl and
stxvl to do the move. Unfortunately, the pattern in the expansion does a
DImode shift left by 56 to get the value into the corre
|UNCONFIRMED |NEW
CC||carll at gcc dot gnu.org,
||meissner at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Michael Meissner ---
Carl Love submitted a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809
--- Comment #4 from Michael Meissner ---
Note, in looking at Carl's patch, it is only for adding the built-ins. I don't
believe it adds direct support for {,u}divti3 and {,u}moddti3 to implement
these for normal __int128 variables.
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
Last reconfirmed||2021-06-04
--- Comment #1 from Michael Meissner ---
This is has been submitted with the patch:
https://gcc.gnu.org/pipermail/gcc-patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809
Michael Meissner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99293
--- Comment #3 from Michael Meissner ---
Created attachment 50947
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50947&action=edit
Proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99293
Michael Meissner changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
I now build GCC with all 3 long double variants (IEEE 128-bit, IBM 128-bit, and
64-bit). The following C test fail when when you configure the compiler to use
64-bit
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
GCC should consider using a sequence of PLI, SLDI, and PADDI to load up 64-bit
constants on power10.
For example
,
||meissner at gcc dot gnu.org,
||segher at gcc dot gnu.org,
||willschm at gcc dot gnu.org,
||wschmidt at gcc dot gnu.org
|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
--- Comment #1 from Michael Meissner ---
I'm working on patches.
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
The current patches that have been submitted to the PowerPC back end need to
grow the precision field in the tree_type_common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #4 from Michael Meissner ---
I must have missed the spare bits. I think it is better to use the full 16
bits for precision. I also think your other changes to realign bit fields
greater than 1 bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
Michael Meissner changed:
What|Removed |Added
Last reconfirmed||2023-02-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #7 from Michael Meissner ---
Created attachment 54387
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54387&action=edit
Proposed patch combining Richard's patch and an assertion.
: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
If you have a DImode variable (i.e. long) in a GPR, and you want to zero extend
it to
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104256
Michael Meissner changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
Michael Meissner changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
On power10, signed conversion from DImode to TImode is inefficient for GCC 11
and the current GCC 12. GCC 10 does not do this optimization.
On power10, GCC tries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104698
--- Comment #3 from Michael Meissner ---
It goes beyond 'just use RTL'.
The problem is the code only generates an altivec instruction. So if the
__int128_t value is in a GPR, the compiler will need to do a move to the vector
registers (1 insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253
Michael Meissner changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868
--- Comment #4 from Michael Meissner ---
In looking at it, the reason is the convert from DImode to TImode has several
constraints. The constraint that matters in this case has the output being an
Altivec register, while the input is a GPR regi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868
Michael Meissner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868
--- Comment #8 from Michael Meissner ---
Matheus, try the patch I just attached to the PR that I posted to the
gcc-patches mailing list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
Michael Meissner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||meissner at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-08-18
--- Comment #3 from Michael Meissner ---
The fold-vec-extract tests work fine on the development version of GCC 13 for
64-bit, but they are
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
I was doing some builds for submitting patches, and I did runs on BE systems as
well as LE systems.
I noticed the test gcc.target/powerpc/bswap64-4.c fails
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
I was doing builds on a power10 system for patch submission, and I noticed the
following test fails when the test is compiled for power10, but it does not
fail
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Target Milestone: ---
I was doing builds on a power10 for patch submission, and I noticed the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345
Michael Meissner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
||2022-01-07
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103763
--- Comment #1 from Michael Meissner ---
Created attachment 52141
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52141&action=edit
Patch to fix the insn count
Update the insn regex for power10.
||2022-01-07
CC||dje at gcc dot gnu.org,
||meissner at gcc dot gnu.org,
||segher at gcc dot gnu.org
Assignee|unassigned at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102935
--- Comment #2 from Michael Meissner ---
Created attachment 52143
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52143&action=edit
Patch to update code generation test
The test wants to load all 1's into a vector register. On power8 it u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102935
Michael Meissner changed:
What|Removed |Added
Attachment #52143|0 |1
is obsolete|
1101 - 1200 of 1289 matches
Mail list logo
