> OK, but what's wrong --with-sysroot=/ ?
It should work, it just seems "wrong" for a native compiler to have a sysroot...
Michael Matz writes:
> syntactic noise without any whitespace. Quite frankly, how anyone could
> ever say that
>
> exp->as_component_ref().get_field()
>
> is easier to read/write/use than
>
> GET_FIELD_DECL (exp)
C vs C++ is not the same argument as style A vs style B. Your argument
could
I assume this is a size_t vs int type problem, but the diagnostic
points to the function declaration, not to an actual binary
expression, and I can't figure out what it's complaining about:
/greed/dj/m32c/gcc/h8300-elf/./gcc/xgcc -shared-libgcc
-B/greed/dj/m32c/gcc/h8300-elf/./gcc -nostdinc++
-
A TPF stack frame has up to two return addresses in it. The second
one is used when the call crosses a shared object domain, where a stub
is between the two functions. The stub does not change the stack, but
it does eventually chain to the "correct" return address.
In the TPF unwinder, a fallba
> style nits: It should be size_t(__len - __pos), and not
> (size_t)(__len - __pos). Same for the other hunk. Patch OK with
> those changes.
Committed that way. Thanks! Ok for 4.7 branch as well?
* include/bits/random.tcc (seed_seq::generate): Cast max()
operands to size_t to
> > Committed that way. Thanks! Ok for 4.7 branch as well?
>
> yes, it is. Thanks,
Done!
> Can any of these stubs throw exceptions? What are they used for?
I suspect they're simple thunks. I can ask what they do.
> My first reaction is to simply consider them invisible system frames
> and ignore them when it comes to unwinding...
That's what we're trying to do, but the CFA corres
> I'm a bit confused as to how the fallback handler can find the correct
> RA but the "normal" unwind path can't.
The fallback knows what address range corresponds to the stubs. It's
"magic".
> How do all these things fit on the stack?
Every stack frame has room for two return addresses.
The
> For rl78 there is a comment in gcc/config/rl78/rl78.h that suggests
> there should be a tablejump insn, but it's not there.
The only unconditional branches rl78 has are immediate and
register-indirect, i.e. "BR $label" and "BR AX".
> This is unfortunate because rl78 is a "#define DWARF2_UNWIND
If I apply this patch, which checks for duplicate hard registers within
-fira-share-save-slots, the following *-elf targets fail due to the assert:
bfin cris m32c rl78 rx sh sh64 v850
The following succeed:
frv h8300 i386 ia64 m32r mep mipsisa32 mipsisa64 mn10300 powerpc tx39
W
> > If I apply this patch, which checks for duplicate hard registers within
> > -fira-share-save-slots, the following *-elf targets fail due to the assert:
> >
> > bfin cris m32c rl78 rx sh sh64 v850
>
> It'd really help if you could probably a testcase so that we could run
> things under a d
dj@greed pts/0 ~/m32c/gcc/rl78-elf/gcc
$ ./cc1 -quiet -O3 qsort.i
DJERR: DUPLICATE HARD REG 12
../../../../../src/newlib/libc/search/qsort.c: In function 'qsort':
../../../../../src/newlib/libc/search/qsort.c:222:1: internal compiler error:
in setup_save_areas, at caller-save.c:574
Please submit
> On Jan 19, 2005, at 22:48, Richard Henderson wrote:
> > On Wed, Jan 19, 2005 at 09:19:58PM -0500, DJ Delorie wrote:
> >> - int regno = 0;
> >> + int regno = FIRST_PSEUDO_REGISTER;
> >
> > To be totally safe, you need LAST_VIRTUAL_REGISTER+1.
>
&g
> I ponder about writing a "i386 16bit realmode" gcc backend as my master
> thesis - which would be usefull for generating 16-bit bios code needed
> by the virtual machine developed at my university.
It's been done a couple of times already, first by me, and later my
code was extended by a couple
> Complex. RM places a 64K stack segment limit. As far as I
> know, GCC requires more than that. Also, GCC was only
> written for 32-bit machines. My suggestions:
You're confusing hosts with targets. GCC *runs on* 32 bit (or more)
hosts, but it can *target* smaller machines. We've got lot
> (insn 28 26 29 1 /mnt/disk2/src/gcc/gcc/libgcc2.c:464 (set (mem/i:HI
> (reg/f:HI 8 si [orig:30 D.1371 ] [30]) [5 +0 S2 A16])
> (subreg:HI (reg/v:DI 31 [ u ]) 0)) 1 {*movhi} (nil)
> (nil))
This is a tricky one. You need to split up the moves early enough to
let reload be flexible,
> (a) the numbers reported by the "time" command,
> (b) what sort of machine this is and how old,
Thinkpad 600 (RHL 9 i386, PII 266MHz) 192Mb (7 yrs old)
real0m46.115s
user0m40.080s
sys 0m3.930s
Dual Opteron 246 (FC3 x86_64, 3GHz) 2Gb (new)
real0m4.344s
user0m3.875s
sys
> > Dual Opteron 246 (FC3 x86_64, 3GHz) 2Gb (new)
>
> Lucky guy! ;)
Oops, I mean 2GHz :-P
(I have another new machine that's a P4 3GHz)
> probably the sanest thing is to go with the automake-like approach of
> one .d file per .c file, which then can be annotated without having to
> write logic to parse a big dependency file and update it in place.
The problem with .d files is that there's no good automatic way to
deal with header
> That script doesn't really parse the file at all, it just scans for
> #include lines, and it processes each header only once no matter how
> many files reference it. Which has got to be faster than what
> cpplib is doing.
Right, I figured you could run it once just to see how *much* faster
it
> Is there a good way of creating an assembler comments directly from RTL?
>
> I want to be able to add debugging/explanation strings to assembler
> listing (GAS). Unfortunately I want to do this from RTL prologue and
> epilogue (and thus avoid using TARGET_ASM_FUNCTION_EPILOGUE - where
> it woul
It seems to me that this kind of bug should have been noticed already,
so... am I missing something?
2005-03-21 DJ Delorie <[EMAIL PROTECTED]>
* optabs.c (expand_binop): Make sure the first subword's result
gets st
> Nick Clifton and I have been discussing the idea of keeping GCC and
> binutils' copy of dwarf.h in sync. I've just resolved all of the
> differences with the binutils version of the file. Perhaps DJ's
> merge script could keep gcc/gcc/dwarf.h in sync with
> src/include/elf/dwarf.h as it does f
> On Mon, 21 Mar 2005, DJ Delorie wrote:
> > 2005-03-21 DJ Delorie <[EMAIL PROTECTED]>
> >
> > * optabs.c (expand_binop): Make sure the first subword's result
> > gets stored.
>
> This is OK for mainline, provided that you bootstrap and r
> Would there be any objection to patches that convert function
> definitions in libiberty to use ISO C prototype style, instead of
> K&R style?
I would be in support of such a patch iff it converts all the
functions, not just the ones gcc happens to use.
> Just to make sure I understand. I was thinking of whatever was
> under $GCC/libiberty (and included). Are you thinking of something
> more?
No.
> A single patch is a huge stuff; I propose to break it into a series
> of patches. Is that OK with you?
I only want to avoid a situation where li
> I take it that all libiberty-using projects have taken the plunge,
> then? You vetoed this conversion awhile back because libiberty had
> to be done last.
At this point, I think libiberty *is* the last.
> What's your opinion on dropping C89 library routines from libiberty?
What would that bu
> Less to maintain is all I was hoping for. I think the configure
> scripts (both libiberty's and gcc's) could be simplified quite a bit
> if we assumed a C89 compliant runtime library, as could libiberty.h
> and system.h.
Well, gcc can make assumptions libiberty can't, and as far as
libiberty's
> Isn't that what newlib is for...?
"Should be" does not mean "is". I know libiberty has been used for
this purpose in the past (remember the demangler in libstdc++ times?)
so I wouldn't want to assume we aren't still doing it.
> I should be clear, though; I only want to make this assumption fo
How to convert this code? There is no single OPT_* that reflects when
the first warning is emitted.
if (params == 0 && (warn_format_nonliteral || warn_format_security))
warning (0, "format not a string literal and no format arguments");
else
warning (O
> To reflect the logical intent of these options while passing a
> unique OPT_* to each warning call, you'd need to add an option
> -Wformat-security-nonliteral for the warnings in the intersection of
> the two options;
At one point I proposed a system that let you say "this option infers
these o
> No company is going to spend money on fixing this until we adjust
> our (collective) attitude and take this seriously.
We could call ulimit() to force everyone to have less available RAM.
Connect it with one of the maintainer flags, like enable-checking or
something, so it doesn't penalize dist
> We already do that for when checking is enabled, well the GC heuristics
> are tuned such that it does not change which is why
> --enable-checking=release is always faster than without it.
Right, but it doesn't call ulimit(), so other sources of memory
leakage wouldn't be affected. I'm thinking
> so I assume setting hard ulimit to 128MB will just result in build
> process crashing instead of slowdown and swapping,
We would limit physical ram, not virtual ram. If you do a "man
setrlimit", I'm talking about RLIMIT_RSS. The result would be slowing
down and swapping, not crashing.
> What I have problem understanding is the last sentence of this
> paragraph in the light of your claim that it will results in
> swapping especially when we consider developers' machines with
> 512MB/1GB RAM, i.e. machines where memory is not "tight".
Sigh, Linux works the same way. Processes c
> So you can say "mem=128m" or the like.
Yes, but that doesn't help when I want to test one application on a
system that's been otherwise up and running for months, and is busy
doing other things. The RSS limit is *supposed* to do just what we
want, but nobody seems to implement it correctly any
> (There's still a POSIX-ism in the generator, in that it tries to
> write to "/dev/null". On Windows systems, I bet this will often
> work, but create a real file with that name. It would be better,
> and avoid portability problems, to guard the calls to fwrite, etc.,
> with "if (file)" rather
> This is still not an answer to the question I originally asked - do you
> see any way IN C to write code which has the relevant property of the
> class above (that is, that the FOOmode constants are not accessible
> except to authorized code) and which does not rely on free conversion
> between
> This doesn't do what I want at all. The goal is to make the *symbolic
> enumeration constants* inaccessible to most code.
Oh.
enum {
THE_VAL_QUUX_ENUMS
} TheValQuux;
If not defined, you get one enum, THE_VAL_QUUX_ENUMS. The "authority"
can define it to a list of enums, so it gets expanded.
>(2) When and if you switch to this:
>
> class machine_mode
> {
> enum value_t {
>VOIDmode, SImode, // ...
> } value;
>
> // accessors, whatever ...
> };
I think what Mark wants is to migrate to this:
class machine_mo
> No, the goal is to make the *values* inaccessible, not the names.
No, *I* want gcc to stop doing *&$@ like this:
stack_parm = gen_rtx_PLUS (Pmode, stack_parm, offset_rtx);
It should use GET_MODE(stack_parm) in case the target has multiple
pointer sizes.
And YES I have a port with multiple
> Furthermore, that does not stop an enthusiastic programmer from
> feeding the interface functions with the wrong values
If you seed the first enum from DATESTAMP, and properly range check,
you can find these cases pretty quickly and abort.
TVQ_SEED = (DATESTAMP%10) * 1000,
TVQ_FOO1,
...
> The cases I've found in my conversion was when codes use plain
> "0" instead of VOIDmode or whatever machine_mode is appropriate.
> That use of plain 0 breaks compilation with a C++ compiler.
If the #include isn't portable enough, just hard code a 42. We'd need
suitable changes for insn-modes
> Might it be more desirable for the compiler's code to only refer to
> target "type" modes as opposed to "size" modes?
Not always, see my mail about Pmode. The problem isn't just how gcc
refers to machine words, but that gcc assumes their usage is context
independent or inflexible. For example
> Now we have e.g. XNEW* and all we need is a new -W* flag to catch
> things like using C++ keywords and it should be fairly automatic to
> keep incompatibilities out of the sources.
Why not this?
#ifndef __cplusplus
#pragma GCC poison class template new . . .
#endif
> where then the target may declare class machine_mode
> target_int_mode ("HI", 16),
This is where we disagree. The *target* shouldn't map types to modes.
The *MI* should map types to modes. The target just creates the modes
it supports and describes them. The MI looks them up by descripti
> - ok, and how does it know that it needs a 32-bit unsigned scalar?
tm.h: #define INT_TYPE_SIZE 32
Combined with "unsigned int foo;" in the user's source file.
The MI doesn't need to know that this fits in a QImode.
> the world is it desirable to go go in a big circle to identify
> which
> which is defined to correspond to some physical mode
Close. Defined to correspond to one or more physical modes.
> - Huh?, can you provide a single example of where a char type would
> be mapped by the target to two different target specified modes?
i386 can hold a char in %al (QImode) o
gcc.dg/compat/struct-layout-1_generate.c assumes sizeof(int) is 4.
This of course fails on any target where sizeof(int) is 2. They may
fail when sizeof(int) is 8 too, or at least they won't be testing the
full range of possibilities.
I've noticed that quite a few testcases make these types of
as
> struct-layout-1_generate.c is run on the host, not on the target.
> And for hosts AFAIK GCC requires 32-bit int.
But the structures it generates assume 32-bit ints:
T(0,enum E2 a:31;,B(0,a,e2_m1,e2_0))
You can't have a 31 bit enum on a 16 bit target. You get messages
like this:
> Some of the work being carried out and posted on the gcc-patches
> mailing list makes those projects seem insignificant in comparision.
There's a wide range of ability in gcc developers, so there's a wide
range of projects to work on. They all use the same *process* so
starting with "trivial"
Consider:
int __attribute__((section("foo"))) *var1;
int * __attribute__((section("foo"))) var2;
var2 is itself in section foo, and points to an int.
Isn't var1 a pointer to something in section foo, and not itself in
foo? GCC instead treats var1 like var2.
I couldn't figure out a suitable se
> "section" attributes are presently storage-class-like (similar to
> "static") and only work on declarations.
Ok, I see that we set the "apply to decl" bit for "section". I guess
the question is - why? Would it be more consistent to keep track of
where it is given, and complain if it is applie
> most code and GCC documentation uses the less clear do-what-I-mean
> positions instead.
Ok, that's kinda what I figured. Thanks!
> if (OPT_Wmissing_braces)
>warning (OPT_Wmissing_braces, "missing braces around
> initializer");
FYI OPT_Wmissing_braces is an enum constant; it will always be nonzero.
> [3]
> warning (OPT_Wmissing_braces, "missing braces around initializer");
That is what we decided t
> So, I assume this patch is wrong in this regard:
> http://gcc.gnu.org/ml/gcc-cvs/2005-06/msg00392.html
Yes, it's wrong in that way.
> [3] shows which options is used to enable/disable that diagnostic
> (assumming it is controled by a particular switch). In either case
> the main diagnostic is always emitted.
No, [3] will also enable/disable the warning, as the OPT_* is used to
look up the variable, and the variable is checke
> The various exceptions of the form "if an attribute is applied to the type
> of a decl which can only apply to a decl, then apply it to the decl" are
> there because they represent forms used by existing code.
What about this scenario?
typedef int __attribute__((section("foo"))) FOOINT;
FOO
> You need to pass the option to warning() also for another reason: we want to
> be able to optionally print which flag can be used to disable each warning,
> so warning() has to be smarter than it used to be.
In addition, we've talked about the idea of having the diagnostic
machinery keep track
> I don't care if it's spelt warn_foo, OPT_Wfoo, warning_p(foo) or
> whatever, so long as it's spelt only one way. The 'warning
> (OPT_Wfoo, ...)' syntax helps only where there is no conditional
> before the warning -- how often does that occur? The way it
> currently is, one runs the risk of wr
> Is that behaviour documented somewhere I missed?
Sadly, no. Actually, none of the diagnostic calls are documented.
The prototypes are even in toplev.h instead of diagnostic.h, between
"fatal_insn_not_found() and "rest_of_decl_compilation()". It's quite
haphazard.
The diagnostic_info structur
>maybe_warning (OPT_Wfoo, frobbed, "foo is frobbed");
>
> This tests whether Wfoo is enabled *before* it evaluates frobbed.
In the cases where such a check is warranted, "frobbed" is usually a
fairly large collection of tests. It would be impractical (and ugly)
to put such logic inside a ma
> Then, you will like the following kind of patches:
>
> + warning (0, "%H undefined behavior if loop runs for more than %qE
> iterations",
> +find_loop_location (loop), estimation);
I think we would like them better if you could choose to silence them,
especially when people u
> Like so? Tested by building outside the source directory and
> attempting to build in the source directory. Did we want something
> like this for mainline too?
We've historically put a lot of effort into making "./configure" work,
so I'd hate to snub anyone willing to work on it. Perhaps an "a
> I also changed the error message to read:
>
> "... is not supported in this release"
>
> Which might work and we can, of course, remove the error message if that
> ever changes :)
>
> OK?
I have no objections, not that I'm the release manager.
> Limitations are:
> * All pointer have Pmode size.
The ability to have various pointer widths would be nice too.
For some chips, like xstormy16 and m16c, function pointers are wider
than other pointers. These types of chips can use thunks to get
around this for gcc, but there are still a few cases when you want to
know the real (>16 bit) address of the function (reset vectors, for
example).
If you use code
My m32c port is generating tracking notes that look like this:
(var_location 0x2a95758dd0 (parallel [
(expr_list:REG_DEP_TRUE (reg/v:SI 0 r0 [orig:123 remainder_size ]
[123])
(const_int 0 [0x0]))
(expr_list:REG_DEP_TRUE (reg:HI 1 r2 [ remainder_size+2 ])
> Even on mainline?
No, one of our branches.
> See PR debug/21946 and
> http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00312.html.
> Var-tracking is very broken in that it doesn't care about register
> modes, but what I have comitted should at least prevent bogus dwarf2
> location list generation.
> Trying to fake two kinds of pointers when we only have one doesn't seem
> wise to me.
>
> A possible solution is to use function descriptors.
Both m32c (my local copy at least) and xstormy use 16 bit thunks to
reference the address of a function outside the first 64k of address
space.
In thi
> DJ, can this be solved by toplevel Makefile.in's dependencies or
> lang_env_dependencies?
The usual solution is to test $with_newlib and hard-code known results
if it's set.
You CANNOT rely on being able to link target programs in all cases.
It's better if you can figure out a non-linking test
> We are just testing if the c compiler can compile. Nothing more at this
> point. I should point out other target libraries have the same problem.
> I pointed Kazu to those bugs last night (I cannot find them right now).
GCC_NO_EXECUTABLES ?
> I've grepped through the entire tree and can't see how the configure
> variable with_multisrctop is ever set to anything than itself.
./config-ml.in sets it as part of the multilib setup, used by
libiberty, newlib, etc.
Please read the ./etc/configure.texi documentation, which explains it.
>
> > I think we would like them better if you could choose to silence them,
> > especially when people use -Werror.
>
> How can I do this?
Create a -W* command line option for it. Pass the corresponding OPT_*
to warning(). Theen the -W option controls that warning.
> I have just mimicked one
> The src directory currently is version 2.0 instead of 2.1 for
> COPYING.LIB. Should the license file be upgraded on src?
Changing licensing terms is usually a question for the FSF, not the
maintainers.
Plus, you should at least bring this up on the binutils/gdb/newlib
lists ;-)
> On Wed, Jul 13, 2005 at 09:56:19PM -0400, DJ Delorie wrote:
> >
> > > The src directory currently is version 2.0 instead of 2.1 for
> > > COPYING.LIB. Should the license file be upgraded on src?
> >
> > Changing licensing terms is usually a questi
> As I understand it, the only difference in the bumped version number
> is the address. Can anyone confirm this?
A simple diff shows other changes, including the all-new shared
library clause and the change of "Library" to "Lesser" in the name.
> If I were to propose a patch, which way should I go?
Why not check out my recently posted -Wpragmas patch on gcc-patches?
It takes a set of existing non-optional warnings, and gives them an
option that can be used to disable them, which defaults to on
(i.e. -Wno-pragmas is the useful option).
> Except that "cp" is already used as a fallback for when "ln" doesn't
> work. If the tool is likely not to work after a "cp" then shouldn't the
> fallback condition be to always create a shell script (or .bat file)?
One could argue that, in the case with ln/cp, we *know* we're dealing
with GNU
> Is that actually true, though? Doesn't GNU ld try to locate files
> relative to its invoked path?
Sometimes, for sysroots and ldscripts. I wouldn't expect MinGW (or
any native linker) to use this feature. GCC usually passes ld
whatever path specifications it needs.
> Since we know that ming
> I build mingw cross toolchains with sysroots :-) That'll be affected
> by this change. Of course, currently I cross-build them from
> --build=i686-linux, so it doesn't affect me directly.
The problem case is build=mingw, not host=mingw. I suppose a
mingw-hosted (and -built) cross compiler mig
> Wouldn't that mean that 'cp' is a valid fallback even for non-GNU lds?
We don't know what *else* a non-gnu linker/assembler might need.
> You already have a not-so-small C program that's supposed to know
> where as and ld are.
You're forgetting about configure.
> I don't see how the existance of configure changes the fact the GCC
> compiler driver exists,
At the time you're running configure, the gcc driver does *not* exist,
but you *do* need to run as and ld to test what features they support,
information which is needed in order to *build* gcc.
It's
http://gcc.gnu.org/wiki/Warning%20Message%20Control
Functionality supported:
* Control of warnings through OPT_* values passed to warning().
* Display of command line options corresponding to printed warnings
through -fdiagnostics-show-option.
Warning conversion:
# OPT # Z
> Presumably, people with blanket write privs and people responsible for
> the build machinery.
Yup, that's them.
I did a little historical digging on this item, and the original
trigger was http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00280.html
where Paolo needed to switch from symlinks to har
> Maybe one solution would be to patch pex-win32 for mingw so that it
> could understand '#!' style shell scripts? That would at least
> allow bootstrapping.
That would be wonderful, and that's exactly the right place to put it
too. I'm assuming I can persuade one of you to do that? ;-)
I'm g
Committed.
* config/mep/mep.c (mep_legitimize_arg): Leave control registers
alone too.
Index: config/mep/mep.c
===
--- config/mep/mep.c(revision 149868)
+++ config/mep/mep.c(working copy)
@@ -6201,13 +6201,15
> Your code uses the (one and only) CRC-32 polynomial 0x04c11db7, so just
> describing it as the "CRC-32" function should be sufficient documentation.
> It's the same CRC function as used by PKZIP, Ethernet, and chksum.
> It's not compatible with the Intel CRC32 instruction which uses the
> CRC-32
On s390x it produces this insn:
(insn 8 7 9 3 323444.c:15 (set (mem/s:DI (reg:DI 46) [0 S8 A64])
(mem/s:DI (reg/v/f:DI 45 [ tp ]) [0 S8 A64])) -1 (nil))
Note that the alignments are 64 bit again, despite the field being
packed. mep-elf has similar results.
void *memcpy(void *dest, co
> * DJGPP
Committed.
2009-08-13 DJ Delorie
* config/i386/djgpp-stdint.h: New.
* config.gcc (djgpp): Use it.
Index: config.gcc
===
--- config.gcc (revision 150731)
+++ config.gcc (working copy)
@@ -1169
If loop optimization assumes sizeof(void *) == sizeof(size_t) and
won't work correctly otherwise, perhaps a check for that condition in
gate_tree_ssa_loop_ivopts() would be appropriate? I thought of just
disabling that flag in m32c.c, but I figured a more generic solution
would make more sense, a
"Joseph S. Myers" writes:
> It has been proposed (and not rejected, but not yet implemented)
I'm still working on it...
> gets from the linker. Since the linker plugin is a shared
> object, and it uses libiberty functions, it needs to use a
> shared libiberty.
Why can't they just link a static libiberty?
Note that the m32c port uses PSImode, so it may offer some suggestions
as example code.
> DJ, can you add these files to the list that we get email about?
Added: ltgcc.m4 ltmain.sh ltoptions.m4 ltsugar.m4 ltversion.m4 lt~obsolete.m4
> But I've previously noted that target libiberty seems completely useless;
It's a target library, like newlib, libz, libstdc++, or anything else.
How do you know there are no target applications that want to link
against it?
> Is it still used outside the "Cygnus tree"?
How should I know? I don't know what users of free software do with
it...
It's a target library. Anyone writing code for any target might use
it.
In tree-ssa-loop-ivopts.c:may_be_unaligned_p(), we call
get_inner_reference to figure out bitpos, but we don't take into
account toffset - which may make the reference less aligned than we
expect. Is this supposed to be accounted for by STEP ? It doesn't
always work with nested arrays - STEP is
I can confirm this fixes my test case. Had I known about
highest_pow2_factor() I might have come up with this myself ;-)
> Index: tree-ssa-loop-ivopts.c
> ===
> --- tree-ssa-loop-ivopts.c(revision 158148)
> +++ tree-ssa-loop-ivo
301 - 400 of 742 matches
Mail list logo
