https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868
Segher Boessenkool changed:
What|Removed |Added
Attachment #52601|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868
--- Comment #3 from Segher Boessenkool ---
Created attachment 52601
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52601=edit
proposed patch
Try the attached, instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868
--- Comment #2 from Segher Boessenkool ---
Well that doesn't do the right thing... mtvsrdd has RA|0. So we either need
some third alternative to handle the case it get assigned hard reg 0, or we
should prevent that some other way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104868
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829
--- Comment #11 from Segher Boessenkool ---
Created attachment 52599
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52599=edit
proposed patch
This patch should restore the previous behaviour. Joseph, can you test it
please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829
--- Comment #10 from Segher Boessenkool ---
(In reply to jos...@codesourcery.com from comment #6)
> The generated .s file has ".machine ppc". Maybe there is some
> inconsistency arising from the use of -mvsx -mfloat128 for this 32-bit
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829
--- Comment #5 from Segher Boessenkool ---
No difference with binutils-2.38 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829
--- Comment #3 from Segher Boessenkool ---
I cannot reproduce it either. The machine instruction that gives the error is
lfiwzx, a power7 insn; GCC will not generate this instruction unless you are
compiling for power7 or later. That is not
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Priority|P3 |P1
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
In <https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591322.html> Joseph
reports that I have broken the default build for powerpc-linux. Whoops.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #30 from Segher Boessenkool ---
There should be a __SIZEOF_IEEE128__ as well, of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #16 from Segher Boessenkool ---
There are many patterns that use VEC_I, and not all have a V1TI variant
currently, so adding V1TI to it is not suitable for now. It is better to
add a new iterator for now.
This whole thing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #27 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #26)
> (In reply to Segher Boessenkool from comment #25)
> > It is defined to __ieee128 whenever that exists, and not defined otherwise?
> > Yes, the logic and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #25 from Segher Boessenkool ---
It is defined to __ieee128 whenever that exists, and not defined otherwise?
Yes, the logic and control flow are byzantine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #23 from Segher Boessenkool ---
Oh, and looks great, thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #22 from Segher Boessenkool ---
In rs6000_type_string, please just handle the error !type_node case first,
so you don't have to consider it in all other cases separately.
Do you need to change the __SIZEOF_FLOAT128__ code at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #20 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #19)
> I'd guess that else ieee128_float_type_node = ibm128_float_type_node =
> long_double_type_node;
> is there so that we don't ICE during the builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #18 from Segher Boessenkool ---
Ah, I didn't see the
else
ieee128_float_type_node = ibm128_float_type_node = long_double_type_node;
which looks completely garbage. It long double is just DP float, we certainly
do not want
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #17 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #13)
> I see
> Doesn't this mean that ieee128_float_type_node and ibm128_float_type_node is
> always non-NULL?
No. All of that code is inside
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104643
--- Comment #3 from Segher Boessenkool ---
Note that the called function is not pure (it writes to some global vars), so
perhaps this was on purpose even? Andreas?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
--- Comment #12 from Segher Boessenkool ---
(In reply to Jonathan Wakely from comment #10)
> Maybe we could do this instead:
>
> --- a/gcc/config/rs6000/rs6000-c.cc
> +++ b/gcc/config/rs6000/rs6000-c.cc
> @@ -623,11 +623,13 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711
--- Comment #8 from Segher Boessenkool ---
Arnd's request was to not have -Wshift-negative-value implied by -W, or at
least not if -fwrapv (-pedantic would be wrong btw, the standard does not
require a diagnostic here, and that is what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104208
--- Comment #2 from Segher Boessenkool ---
If you want -mlong-double-64 to override -mabi={ibm,ieee}longdouble, you need
make sure that the last of those options on the command line wins. And what
should -mlong-double-128 do in that scheme?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711
--- Comment #4 from Segher Boessenkool ---
Created attachment 52522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52522=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711
--- Comment #3 from Segher Boessenkool ---
... does NOT have a good enough balance ...
Sorry :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2022-02-27
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104698
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104698
--- Comment #1 from Segher Boessenkool ---
GCC should not use unspecs for any basic operations like this. *That* is
the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #22 from Segher Boessenkool ---
Well, we do not do anything AT here; but the patch is not on the GCC 11
branch either.
Xiong Hu, does it backport there cleanly?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104681
--- Comment #4 from Segher Boessenkool ---
We also do the same in define_insn bodies, with a force_reg if needed.
But we do indirect via rs6000_emit_move elsewhere, so let's do that here as
well; it isn't a great idea, but consistency wins,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104681
--- Comment #2 from Segher Boessenkool ---
Could you just change the insn condition to test if at least one of the
operands is a reg?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |REOPENED
--- Comment #20 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
--- Comment #19 from Segher Boessenkool ---
And the same with all of GCC 8, GCC 9, GCC 10, GCC 11, and current trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085
Segher Boessenkool changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #18 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103353
--- Comment #7 from Segher Boessenkool ---
(In reply to Kewen Lin from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > You miss all extra errors the expand_call can generate. This is the general
> > reason why we try to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103926
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2022-02-23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88197
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104627
--- Comment #4 from Segher Boessenkool ---
The old warning was more helpful and specific, it would be nice if we could
have that back.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103353
--- Comment #4 from Segher Boessenkool ---
You miss all extra errors the expand_call can generate. This is the general
reason why we try to continue instead of stopping after the first error. The
reason is that later errors may be more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104627
--- Comment #2 from Segher Boessenkool ---
It started somewhere in the last four days:
-Compiler version: 12.0.1 20220217 (experimental) (GCC)
+Compiler version: 12.0.1 20220221 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #31 from Segher Boessenkool ---
A straightforward backport of that gives
In file included from /home/segher/src/gcc/gcc/config/rs6000/rs6000.cc:28765:
./gt-rs6000.h:143:6: error: 'atomic_update_decl' was not declared in this scope
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
New regressions:
-m32:
+FAIL: gcc.dg/deprecated.c (test for warnings, line 28)
+FAIL: gcc.dg/deprecated.c (test for excess errors)
and that warning is
/home/segher/src/gcc/gcc/testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98179
Segher Boessenkool changed:
What|Removed |Added
Resolution|INVALID |WORKSFORME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134
--- Comment #30 from Segher Boessenkool ---
(In reply to Richard Biener from comment #28)
> Huh, yes - I assumed that had been fixed. Segher? Can you please fix that
> GTY bug?
I'll look at it. It's over three years old, will need some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #30 from Segher Boessenkool ---
Btw, does this issue exist for the corresponding __builtin_{un,}pack_ibm128
builtins as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #29 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #28)
> (In reply to Segher Boessenkool from comment #27)
> > OTOH, it makes no sense to test if we have hard float. The pack and unpack
> > builtins should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104024
--- Comment #3 from Segher Boessenkool ---
Most of those options were removed. Does this problem (adjusted properly,
those options are now enabled iff you use -mcpu=power10 or later) still
happen on trunk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103623
--- Comment #27 from Segher Boessenkool ---
OTOH, it makes no sense to test if we have hard float. The pack and unpack
builtins should work (and work the same) whenever long double is double-double.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104595
--- Comment #2 from Segher Boessenkool ---
This is exactly the same as the char case here though, so it is a bit silly
that we miss it :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104590
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91903
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104353
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95082
--- Comment #9 from Segher Boessenkool ---
It still needs fixing on trunk as well, as discussed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
--- Comment #8 from Segher Boessenkool ---
So I am wondering if this is something we want to do at all. It seems not
suitable for stage 4 at all.
The problem is that a "comparison" of a CC against 0 is not a comparison
at all, but the result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104446
--- Comment #5 from Segher Boessenkool ---
This testcase is invalid code of course, so anything can happen. ICEs are bad
though ;-)
Please add to the comment that you don't want this substitution because it
leads
to ICEs, and mention the PR #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104438
--- Comment #3 from Segher Boessenkool ---
Also combine could work that late in principle: it can deal with hard
registers, after all. But it would be a terrible idea. A single combine
pass is expensive enough, we don't want to run it N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
--- Comment #12 from Segher Boessenkool ---
(In reply to HaoChen Gui from comment #11)
> Segher,
> Will you commit your patch in stage4? Several issues are supposed to be
> fixed by your patch. Thanks.
Yes, of course, but there have been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101885
--- Comment #12 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #8)> The failed match attempt
> (parallel [
> (set (reg:QI 82 [ b_lsm_flag.26 ])
> (and:QI (reg:QI 143)
> (reg:QI 145)))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
--- Comment #5 from Segher Boessenkool ---
(In reply to rdapp from comment #4)
> originally ifcvt would only pass e.g.
>
> (unle (reg:SF 129 [ _29 ])
> (reg/v:SF 118 [ highScore ]))
>
> as condition to rs6000_emit_cmove via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104335
--- Comment #3 from Segher Boessenkool ---
Hi Robin,
Can you please explain what really happens now? What arguments
rs6000_emit_cmove
is called with, and when that goes wrong?
||segher at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #5 from Segher Boessenkool ---
Should be fixed now.
|--- |FIXED
CC||segher at gcc dot gnu.org
--- Comment #3 from Segher Boessenkool ---
Raoni says this is fixed now. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104172
--- Comment #14 from Segher Boessenkool ---
I already approved the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194
--- Comment #5 from Segher Boessenkool ---
Abusing complex fp, what a dastardly plan! :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194
--- Comment #1 from Segher Boessenkool ---
Maybe we should say what actual mode is used in the DWARF info, not the C
way of getting there? So something that denotes DP / double-double / QP,
for our three options for long double?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
--- Comment #8 from Segher Boessenkool ---
Somewhat more constructive... The problem here is that neg isn't pushed
"through" isel insns. This in general means you need to negate both inputs
to the isel of course, but there are cases where that
||segher at gcc dot gnu.org
--- Comment #2 from Segher Boessenkool ---
Do you have a testcase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95737
--- Comment #7 from Segher Boessenkool ---
> Seems cmp+isel on P9 is sub-optimal.
For this particular test, perhaps. But it is better overall, at least some
years ago. It was benchmarked (with spec), on p9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97071
--- Comment #8 from Segher Boessenkool ---
(In reply to Richard Biener from comment #7)
> Another possibility would be to do this on GIMPLE, creating parts of the
> constant pool early with CONST_DECLs and loads from them for constants that
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
Segher Boessenkool changed:
What|Removed |Added
CC||npiggin at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102169
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197
--- Comment #9 from Segher Boessenkool ---
Created attachment 52131
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52131=edit
Proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103686
--- Comment #8 from Segher Boessenkool ---
It is an internal (debugging) option. It isn't documented in the manual, but
indeed it is not marked as Undocumented in rs6000.opt .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #18 from Segher Boessenkool ---
Yes, it is slow. Five sequential dependent integer instructions instead of
one load instruction. Depending on how you benchmark this you possibly won't
see the slowness, the values are stored to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103860
--- Comment #7 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 52089 [details]
> gcc12-pr103860.patch
>
> Not sure I understand what you'd like to see.
Exactly what you did :-) Well, I didn't see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102923
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103860
--- Comment #5 from Segher Boessenkool ---
That looks good. But can you always set maybe_check_pro to true (and then
optimise it away of course)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #19 from Segher Boessenkool ---
(In reply to luoxhu from comment #17)
> And what do you mean"This is not canonical form on RTL, and it's not a
> useful form either" in c#7, please? Not understanding the point...
On Gimple it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90323
--- Comment #18 from Segher Boessenkool ---
(In reply to luoxhu from comment #16)
> > +2016-11-09 Segher Boessenkool
> > +
> > + * simplify-rtx.c (simplify_binary_operation_1): Simplify
> > + (xor (and (xor A B) C) B) to (ior (and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #13 from Segher Boessenkool ---
If we need more than three insns to create a constant we are better off loading
it from memory, in all cases. Maybe three is too much already, at least on
some processors?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281
--- Comment #12 from Segher Boessenkool ---
This is my g:72b2f3317b44, two years and a day old :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68150
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624
Segher Boessenkool changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103739
--- Comment #4 from Segher Boessenkool ---
Thanks. But the point of this PR is that bootstrapping trunk is broken.
That needs fixing some way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103739
--- Comment #2 from Segher Boessenkool ---
Hi!
I have no idea why not.
$ gdc --version
gdc (GCC) 9.3.1 20200410
and it says
Configured with: /home/segher/src/gcc/configure --prefix=/home/segher/tot
Assignee: ibuclaw at gdcproject dot org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
gdc -fno-PIE -c -g -O2 -fversion=IN_GCC -Wall -Wdeprecated -fno-common -o
d/access.o -MT d/access.o -MMD -MP -MF d/.deps/access.TPo
-I/home/segher/src/gcc/gcc/d -J/home/segher/src
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624
--- Comment #8 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #6)
> We have __builtin_darn_32 for the 32-bit case. The changes for the two
> 64-bit-only interfaces reflect the previous behavior.
No, that has nothing to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624
--- Comment #5 from Segher Boessenkool ---
It should work for 32-bit though?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995
--- Comment #11 from Segher Boessenkool ---
Yeah, that could be much more robust.
OTOH this stuff is completely opportunistic in the first place: it handles
only function return values, not any other hard registers (like local
register vars).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100736
--- Comment #3 from Segher Boessenkool ---
Send patches to gcc-patches@, please. Or is there a question? Ask that
question then, please :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995
--- Comment #9 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #7)
> What is this REG_RETURNED thing?
Ah, something added in ira-lives.c, and you call *that* code fragile?
I agree :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995
--- Comment #8 from Segher Boessenkool ---
Also, what is fragile here? This is *removing* fragility and premature
choices!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101995
--- Comment #7 from Segher Boessenkool ---
I don't see any problem with aarch64 fwiw.
If RA decides it does not want to tie the new pseudo to the argument
register, it may have a reason for it? Or suboptimal heuristics.
What is this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103568
Segher Boessenkool changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103568
--- Comment #1 from Segher Boessenkool ---
Confirmed.
This is cheaper in GPRs until we had the lxvrdx insn, which is power10 (ISA
3.1)
itself.
Wrt dword 1 being zeroed by fp insns. ISA 3.1 has a note saying this was true
on all earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102239
--- Comment #10 from Segher Boessenkool ---
(In reply to luoxhu from comment #9)
> > It does matter, if what you are want to see is if it is smaller than zero or
> > greater than zero. CCmode includes those things. There is a CCEQmode for
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54063
--- Comment #23 from Segher Boessenkool ---
Trunk does
lookup:
.quad .L.lookup,.TOC.@tocbase,0
.previous
.type lookup, @function
.L.lookup:
.LFB0:
.cfi_startproc
addis 9,2,.LANCHOR0@toc@ha
ld
401 - 500 of 3161 matches
Mail list logo