Richard Guenther wrote:
> On Mon, Feb 20, 2012 at 11:19 PM, Ulrich Weigand wrote:
> > we've noticed that the loop optimizer sometimes inserts weirdly
> > inefficient code to compute the value of an induction variable
> > at the end of the loop.
[snip]
> The issue i
Richard Guenther wrote:
> On Tue, 28 Feb 2012, Ulrich Weigand wrote:
> > On powerpc64-linux, testing is still ongoing (I had to re-do the
> > baseline run ... b.t.w. this showed that the vect-outer- tests
> > also fail on this target currently).
> >
> > OK once t
SI (match_operator:SI 3 "sat_shift_operator"
+ [(match_operand:SI 4 "s_register_operand" "r")
+ (match_operand:SI 5 "const_int_operand" "i")])
+ (match_operand:SI 1 "const_int_operand" "i"))
+(match_operand:SI 2 "const_int_operand" "i")))]
+ "TARGET_32BIT && arm_arch6 && !=
+ && arm_sat_operator_match (operands[], operands[],
NULL, NULL)"
+{
+ int mask;
+ bool signed_sat;
+ if (!arm_sat_operator_match (operands[], operands[],
+ &mask, &signed_sat))
+gcc_unreachable ();
+
+ operands[1] = GEN_INT (mask);
+ if (signed_sat)
+return "ssat%?\t%0, %1, %4%S3";
+ else
+return "usat%?\t%0, %1, %4%S3";
+}
+ [(set_attr "predicable" "yes")
+ (set_attr "insn" "sat")
+ (set_attr "shift" "3")
+ (set_attr "type" "alu_shift")])
;; Shift and rotation insns
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
al first.
I've already checked the patch in to 4.6 too -- the tests newly enabled
by it all pass there as well.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
o be existing precedent
e.g. FCVT in vfp.md ...
But if you prefer to have them in iterators.md anyway, I'll be
happy to move them, of course.
> Ok with that change for 4.8 if no regressions.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
x27;s a patch that implements your suggestion.
Tested on arm-linux-gnueabi, i386-linux-gnu and s390-linux-gnu.
OK for mainline?
Bye,
Ulrich
2012-03-07 Ulrich Weigand
gcc/
* combine.c (apply_distributive_law): Do not distribute SUBREG.
=== modified file 'gcc/combine.c'
of gen_reload doesn't
work, but at least we'll get an ICE instead of wrong code now.
Those cases will have to be fixed by the back-end as described
above ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
is is then
rejected by the back-end, I don't think we need to change anything
in gen_reload ...
With your change below, it seems you're just falling through to
the generic gen_rtx_SET case, right? How does this help?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
H.J. Lu wrote:
> On Mon, Jun 27, 2011 at 7:52 AM, Ulrich Weigand wrote:
> > H.J. Lu wrote:
> >
> >> Given input:
> >>
> >> (plus:SI (subreg:SI (plus:DI (reg/f:DI 7 sp)
> >> =A0 =A0 =A0 =A0 =A0 =A0 (const_int 16 [0x10])) 0)
> >> =A0 =A0 (
H.J. Lu wrote:
> On Mon, Jun 27, 2011 at 7:47 AM, Ulrich Weigand wrote:
> > The actual problem
> > here is that this part of gen_reload takes the approach to transform
> >
> > out <- op0 + op1
> >
> > into
> >
> > out <- op0
> &g
ls through to the last attempt, which is to
instead copy the subreg to the destination (which results in insn 1022
as the subreg is optimized away at this point), followed by adding the
constant.
Note that the point marked with "[** which is broken **]" is the place
I pointed out in the previous mail.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
why I hadn't expected this to be a problem here.
Can you try to find out why the find_replacement doesn't work
with your test case?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
adreg && GET_CODE (*loc) == SUBREG
! && r->where == &SUBREG_REG (*loc))
{
! return gen_rtx_REG (GET_MODE (*loc),
! (REGNO (reloadreg)
! + subreg_regno_offset (REGNO (SUBREG_REG (*loc)),
GET_MODE (SUBREG_REG
(*loc)),
SUBREG_BYTE (*loc),
GET_MODE (*loc;
}
}
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
if (r->mode != VOIDmode && GET_MODE (reloadreg) != r->mode)
! reloadreg = reload_adjust_reg_for_mode (reloadreg, r->mode);
return reloadreg;
}
! else if (reloadreg && GET_CODE (*loc) == SUBREG
! && r->wh
descent instead of via SUBREG_LOC.
> >>
> >
> > It works much better. I am testing it now.
> >
>
> It works. There are no regressions on Linux/ia32 nor Linux/x86-64.
> Can you check it in and mention PR rtl-optimization/49114 ChangeLog?
OK, I've chec
#if ! defined (LOAD_EXTEND_OP) && ! defined (WORD_REGISTER_OPERATIONS)
*** push_reload (rtx in, rtx out, rtx *inloc
*** 1163,1169
--- 1167,1175
#endif
))
{
+ #ifdef LIMIT_RELOAD_CLASS
out_subreg_loc = outloc;
+ #endif
outloc = &SUBREG_REG (out);
out = *outloc;
#if ! defined (LOAD_EXTEND_OP) && ! defined (WORD_REGISTER_OPERATIONS)
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ounts according to BYTES_BIG_ENDIAN,
not BITS_BIG_ENDIAN -- which exactly cancels out the common code behaviour
introduced by your patch ...
Thoughts? Am I overlooking something here?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
dress*, i.e. use address_mode. If
this is not true (has changed?) a lot of other places would need to
change as well ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
mode (the mode of the address argument to MEM).
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Guenther wrote:
> On Tue, Jul 5, 2011 at 4:56 PM, Ulrich Weigand wrote:
> > Can you elaborate? =A0We are talking about the mode returned from
> > addr_for_mem_ref here. =A0I do now understand how this can be anything
> > but an address mode:
>
> That
Richard Sandiford wrote:
> gcc/
> * reload1.c (choose_reload_regs): Use mode sizes to check whether
> an old relaod register completely defines the required value.
>
> gcc/testsuite/
> * gcc.target/arm/neon-modes-3.c: New test.
This is OK.
Thanks,
Ulrich
_5 = (void *) D.1963_3;
test.i:3:1: internal compiler error: verify_gimple failed
Any thoughts?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Guenther wrote:
> 2011-07-13 Richard Guenther
>
> * tree-vrp.c (simplify_conversion_using_ranges): Make sure
> the final type is integral.
This fixes the spu-elf build failure.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z
finished processing
- * them. */
- static void
- asm_file_start (void)
- {
- default_file_start ();
- }
-
/* Implement targetm.section_type_flags. */
static unsigned int
spu_section_type_flags (tree decl, const char *name, int reloc)
--- 7037,7042 ----
--
Dr. Ulrich Weigand
GNU To
t(mode, -1);
+ })
+
(define_expand "ffs2"
[(set (match_dup 2)
(neg:VSI (match_operand:VSI 1 "spu_reg_operand" "")))
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Bernd Schmidt wrote:
> On 07/13/11 21:22, Ulrich Weigand wrote:
> > several builtin-bitops-1.c tests have been failing recently on SPU
> > since the new clrsb builtin is not supported.
>
> That's odd, it should just have picked the libgcc function rather than
> caus
tempt to
use it across a function call (*any* function call) anyway;
but if the register is call-saved, setjmp really ought to
restore the old value, *both* times it returns, and so reuse
ought to be allowed ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
be restricted to those targets that actually support
that OS feature?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Hans-Peter Nilsson wrote:
> On Thu, 14 Jul 2011, Ulrich Weigand wrote:
> > I see that this went already in, but I'm wondering why this
> > change should be necessary. As far as register use is
> > concerned, setjmp ought to behave just like a regular function:
> >
ts.
Maybe get_object_alignment should itself handle SSA_NAMEs?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
m_attributes_minus_bitpos (rtx ref
*** 1845,1850
--- 1845,1851
}
/* Now set the attributes we computed above. */
+ attrs.addrspace = TYPE_ADDR_SPACE (type);
set_mem_attrs (ref, &attrs);
/* If this is already known to be a scalar or aggregate, we are done. */
--
provided some
address spaces; on i386 you could e.g. implement "far" segmented
pointers as an address space; or you could at least implement
the %gs: segment as an address space and use it to implement
TLS accesses ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on S
Richard Guenther wrote:
> On Tue, Jul 19, 2011 at 8:20 PM, Ulrich Weigand wrote:
> > The problem is that in this expression
> > disappear = VIEW_CONVERT_EXPR(x_8);
> > the rhs is considered unaligned and blocks the SRA transformation.
> >
> > The check yo
bb is now always NULL at this point, and the assignment crashes.
I guess that assignment should now be just deleted as well, since
this is done by create_basic_block later?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
a[j] = a[i] + 1;
> + return a[0];
> +}
> +
> +int
> +main (void)
> +{
> + int res = foo ();
> + if (res != 1999)
> +abort ();
> + return 0;
> +}
The return value of foo with vectorization is 1249 instead
of 1999 for some reason.
Bye,
Ulrich
--
Richard Henderson wrote:
> On 07/20/2011 11:24 AM, Ulrich Weigand wrote:
> >> >BB_HEAD (new_bb) = new_label;
> > new_bb is now always NULL at this point, and the assignment crashes.
> >
> > I guess that assignment should now be just deleted a
ing via command line switch? Maybe just decrease
*some* dimensions of the tmp1 array?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
xt+0x28): undefined reference to `sqrt'
because nothing links against libm. I'm a bit confused by the comment
above: even with the linker plugin, where should libm be pulled in?
Don't we need to use -lm on the linker line anyway?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Guenther wrote:
> On Fri, 22 Jul 2011, Ulrich Weigand wrote:
> > Now that we have the linker plugin, this fails on spu-elf with:
> >
> > /tmp/cce6KuRb.ltrans0.ltrans.o: In function `foo':
> > cce6KuRb.ltrans0.o:(.text+0x28): undefined reference to `sqrt
Richard Henderson wrote:
> On 07/22/2011 07:42 AM, Ulrich Weigand wrote:
> > Well, it works for me with just adding -lm to the dg-extra-ld-options.
> > This still folds cabs to sqrt in the LTO step, and then satisfies that
> > call via the libm routine ... If I understood
ned, and therefore the data it points to can be
accessed via a simple load, with no extra rotate needed.
It seems what happened here is that somehow, a pointer to int
gets replaced by a pointer to vector, even though their alignment
properties are different.
This vector pointer must originate somehow in the vectorizer,
however, since the original C source does not contain any
vector types at all ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Ira Rosen wrote:
> "Ulrich Weigand" wrote on 22/07/2011 05:05:57 PM:
> > Any suggestions how to fix this? Maybe decrease N again and instead
> > prevent unrolling via command line switch?
>
> There is no flag for this unrolling, but we can run the test with -O1
ned
value into a vector pointer variable. It then generates a check
whether the value is really aligned; and uses it only if so.
But if that pointer variable "escapes" into the other branch because
DOM thinks it can re-use the value, the REGNO_POINTER_ALIGN value
carried for its DECL_RTL register is now incorrect ...
Maybe the vectorizer ought to declare that variable with a non-default
type alignment setting? Or else, perform the assignment to the
variable only *inside* the "if" that checks for correct alignment?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
reg Y introduces the
potential misalignment. If on the other hand neither of the base
registers is guaranteed to be 128-bit aligned, I need to generate
more complex rotate code ...
I understand this may also be important on other platforms, e.g.
to choose which register to use as base and which as index in a
memory operation ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Guenther wrote:
> On Mon, Jul 25, 2011 at 4:23 PM, Ulrich Weigand wrote:
> > I had always understood this to reflect the simple fact that a
> > pointer to some type must never hold a value that is not properly
> > aligned for that type. (Maybe this is only tru
his does fix the testcase that was failing on SPU.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Richard Guenther wrote:
> On Mon, Jul 25, 2011 at 5:25 PM, Ulrich Weigand wrote:
> > When would that be? The expansion does happen in the initial expand
> > stage, but I'm getting called from the middle-end via emit_move_insn etc.
> > which already provides me with a ME
Michael Matz wrote:
> On Tue, 26 Jul 2011, Michael Matz wrote:
> > On Tue, 26 Jul 2011, Ulrich Weigand wrote:
> >
> > > > Well, REG_ATTRS->decl is again a decl, not an SSA name. I suppose
> > > > we'd need to pick a conservative REGNO_POINTER
sed via DMA) ...
Can the test be extended to actually check for the mmap routine
itself?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ion with -pthread is error-free for trivial
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
h
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Martin Jambor wrote:
> On Wed, Jul 27, 2011 at 02:34:59PM +0200, Ulrich Weigand wrote:
> > I'm seeing the same failure on the 4.6 branch -- would this patch also be
> > appropriate there?
>
> You're right, it should be applied to the 4.6 branch too. Since you
&g
Martin Jambor wrote:
> On Wed, Jul 27, 2011 at 02:34:59PM +0200, Ulrich Weigand wrote:
> > Martin Jambor wrote:
> >
> > > OK, this is what I have just committed as revision 176797 after
> > > re-testing.
> >
> > Thanks, this has fixed the f
ld_function_type in itself implies an
upper bound on the number of supported arguments.)
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Nathan Froyd wrote:
> * config/s390/s390.c (s390_init_builtins): Call
> build_function_type_list instead of build_function_type.
This is OK.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
---
if (!sibcall_p)
{
emit_use (gen_rtx_REG (SImode, LINK_REGISTER_REGNUM));
! emit_jump_insn (gen__return ());
}
}
rtx
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
return si_to_TItype (total);
}
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
hedule_ready) (insn);
+ VEC_safe_push (rtx, heap, scheduled_insns, insn);
+
+ last_scheduled_insn = insn;
return insn;
}
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
also passes the testsuite with
no regressions).
OK for the 4.5 branch?
Bye,
Ulrich
2011-04-27 Ulrich Weigand
PR middle-end/43085
Backport from mainline:
2010-04-29 Bernd Schmidt
From Dominique d'Humieres
PR bootstrap/43858
* if
aspects, but I wasn't sure attempting to pull those apart was a safer option,
given that at least in its current form it has seen testing in mainline ...
I'd certainly be happy to try out a more stripped down patch; could you be
more specific about exactly which parts you want me to omit?
> it's probably better to backport the unmodified changes. Thanks.
OK, thanks.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Bernd Schmidt wrote:
> On 04/27/2011 03:22 PM, Ulrich Weigand wrote:
> > * haifa-sched.c (sched_emit_insn): Emit insn before first
> > non-scheduled insn. Inform back-end about new insn. Add
> > new insn to scheduled_insns list.
>
> Seems like this funct
(type);
size = int_size_in_bytes (type);
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
tch was committed ...
I'm not quite sure how to fix this ... any suggestions? Did this problem
occur in the past when newlib was extended to provide some new function?
I guess the immediate build problem will disappear once the libiberty
prototype is fixed to include const, but then we'll j
t;, op);
+ output_asm_insn ("a\t%7,%7,%6", op);
+ }
+
+ output_asm_insn ("lqd\t%6,0(%7)", op);
+ output_asm_insn ("rotqby\t%6,%6,%7", op);
+ output_asm_insn ("a\t%1,%1,%6", op);
+ }
+
+ /* Jump to target. */
+ output_asm_insn ("br\t%0", op);
+
+ final_end_function ();
+ }
+
#include "gt-spu.h"
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
libiberty, but the
symbol psignal is defined within strsignal.c; and 2.) strsignal.o is already
added unconditionally to the list of libiberty objects ... [ But even if we
*did* split psignal into its own object file, that would still not answer
the question of when to link it in and when not
uld
seem to be just wierd ...)?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
r updating
the version field?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
is only triggered by DW_CFA_val_... CFI statements, which are new
in Dwarf-3 and seem to be very rarely used: they are apparently never
generated by GCC, and the only files I could find in current glibc that
create such CFI by hand are Intel-specific.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ABI considerations and need for further versioning ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ress_reloaded flag.
> (find_reloads_address_1): Don't use address_reloaded parameter.
This is OK.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
VOIDmode, scratch_or_premodify);
Maybe replace_equiv_address instead, to avoid losing the memory
attribute information (alignment, alias set, ...)?
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
ine FLOAT' > fp-bit.c
--- 56,62
DPBIT = dp-bit.c
dp-bit.c: $(srcdir)/config/fp-bit.c $(srcdir)/config/spu/t-spu-elf
! cat $(srcdir)/config/fp-bit.c > dp-bit.c
fp-bit.c: $(srcdir)/config/fp-bit.c $(srcdir)/config/spu/t-spu-elf
echo '#define FLOAT&#x
Andreas Krebbel wrote:
>gcc/ChangeLog:
>PR target/102024
>* config/s390/s390-protos.h (s390_function_arg_vector): Remove
>prototype.
>* config/s390/s390.cc (s390_single_field_struct_p): New
function.
>(s390_function_arg_vector): Invoke s390_single_field_str
get clarity here as I'm about to work on this
for clang ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
On Sat, Nov 21, 2020 at 01:57:32PM -0600, Segher Boessenkool wrote:
> On Fri, Nov 20, 2020 at 09:33:48PM -0700, Jeff Law wrote:
> > On 2/11/20 11:43 AM, Ulrich Weigand wrote:
> > > 1. If a component flag of -ffast-math (or -funsafe-math-optimizations)
> > >is expli
her
with fast-math or no-fast-math is excess-precision=fast, so again
it should not be touched.
I'll still need to look into the language-specific handling of the
excess precision setting to make sure this works for all languages.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
ors you're seeing, it would
probably be OK to go with just this minimal change -- unless we can
just move to LRA as mentioned above.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU/Linux compilers and toolchain
ulrich.weig...@de.ibm.com
Is this
> always true? */
No, it could be either way. But it shouldn't really matter since
you just need to apply the same displaced offset to the target,
whether the offset is positive or negative. Again, you should
just do it the same way it is already done by existing code
that ha
On Thu, Mar 25, 2021 at 12:21:42PM -0500, will schmidt wrote:
> On Wed, 2021-03-10 at 18:50 +0100, Ulrich Weigand wrote:
> > Will Schmidt wrote:
> >
> > > This is a patch written by Alan Modra. With his permission
> > > I'm submitting this fo
401 - 480 of 480 matches
Mail list logo
