Accidentally committed from the wrong path, which apparently had some cruft
in it. I've reverted this in r235750.
- Lang.
On Fri, Apr 24, 2015 at 12:04 PM, Lang Hames lha...@gmail.com wrote:
Author: lhames
Date: Fri Apr 24 14:04:55 2015
New Revision: 235749
URL: http://llvm.org/viewvc/llvm
Author: lhames
Date: Fri Apr 24 14:04:55 2015
New Revision: 235749
URL: http://llvm.org/viewvc/llvm-project?rev=235749view=rev
Log:
[CodeGen] Make AsmPrinter's OutStreamer member a unique_ptr.
AsmPrinter owns the OutStreamer, so an owning pointer makes sense here. Using a
reference for this is
Author: lhames
Date: Fri Apr 24 14:08:30 2015
New Revision: 235750
URL: http://llvm.org/viewvc/llvm-project?rev=235750view=rev
Log:
Revert r235749 - Accidentally commited cruft from the wrong path.
Modified:
cfe/trunk/tools/driver/driver.cpp
Modified: cfe/trunk/tools/driver/driver.cpp
URL:
Awesome. Thanks for fixing this Takumi!
On Thu, Dec 5, 2013 at 6:00 PM, NAKAMURA Takumi geek4ci...@gmail.comwrote:
Author: chapuni
Date: Thu Dec 5 20:00:41 2013
New Revision: 196559
URL: http://llvm.org/viewvc/llvm-project?rev=196559view=rev
Log:
Author: lhames
Date: Wed Dec 4 18:33:58 2013
New Revision: 196439
URL: http://llvm.org/viewvc/llvm-project?rev=196439view=rev
Log:
If the LLVM OBJ_DIR path contains any characters not listed in the
ScalarSafeChars array in Output::scalarString (See YAMLTraits.cpp line 554 as
of r196428), this
Author: lhames
Date: Thu Dec 5 00:17:42 2013
New Revision: 196474
URL: http://llvm.org/viewvc/llvm-project?rev=196474view=rev
Log:
Re-apply r196439, with sed patterns modified to be more DOS-path friendly.
Modified:
clang-tools-extra/trunk/test/clang-modernize/HeaderReplacements/main.cpp
...@gmail.comwrote:
Lang, reverted in r196460, excuse me.
2013/12/5 NAKAMURA Takumi geek4ci...@gmail.com:
It seems win32 builders don't like this.
See; http://bb.pgr.jp/builders/cmake-clang-i686-mingw32/builds/6122
I will investigate it, later, too.
2013/12/5 Lang Hames lha...@gmail.com
Thanks for that Rafael!
On Sat, Nov 23, 2013 at 6:41 AM, Rafael Espíndola
rafael.espind...@gmail.com wrote:
r195551
On 29 October 2013 00:03, Rafael Espíndola rafael.espind...@gmail.com
wrote:
On 28 October 2013 23:28, Lang Hames lha...@gmail.com wrote:
Hi Rafael,
I noticed
Hi Rafael,
Are you likely to be able to make a proper fix for this soon? If not I
think it should be reverted for now - it's still broken.
Cheers,
Lang.
On Mon, Nov 18, 2013 at 4:02 PM, Lang Hames lha...@gmail.com wrote:
Hi Guys,
Any further thoughts on this? I'd keen to see it fixed one
rafael.espind...@gmail.com wrote:
On 28 October 2013 23:28, Lang Hames lha...@gmail.com wrote:
Hi Rafael,
I noticed that as a consequence of this patch, clang is issuing the
following warning when assembling for arm:
'+soft-float-abi' is not a recognized feature for this target (ignoring
Hi Rafael,
I noticed that as a consequence of this patch, clang is issuing the
following warning when assembling for arm:
'+soft-float-abi' is not a recognized feature for this target (ignoring
feature)
You can reproduce this (at least on Darwin, and I expect on Linux too) by
creating an empty
Author: lhames
Date: Tue Mar 5 14:27:24 2013
New Revision: 176512
URL: http://llvm.org/viewvc/llvm-project?rev=176512view=rev
Log:
Use ASTContext::getDeclAlign(Field Decl) to get the alignment of the first
field to be memcpy'd, rather instead of ASTContext::getTypeAlign(Field Type).
For packed
Author: lhames
Date: Tue Feb 26 22:14:49 2013
New Revision: 176163
URL: http://llvm.org/viewvc/llvm-project?rev=176163view=rev
Log:
Use the correct alignment for POD-member memcpys where the first field is a
bitfield. CGBitField::StorageAlignment holds the alignment in chars, but
emitMemcpy had
Author: lhames
Date: Sun Feb 17 04:18:28 2013
New Revision: 175392
URL: http://llvm.org/viewvc/llvm-project?rev=175392view=rev
Log:
Remove block names from test case to unbreak release builds.
Thanks Chandler. :)
Modified:
cfe/trunk/test/CodeGenCXX/pod-member-memcpys.cpp
Modified:
Author: lhames
Date: Sun Feb 17 01:22:09 2013
New Revision: 175389
URL: http://llvm.org/viewvc/llvm-project?rev=175389view=rev
Log:
Re-apply r174919 - smarter copy/move assignment/construction, with fixes for
bitfield related issues.
The original commit broke Takumi's builder. The bug was caused
Author: lhames
Date: Mon Feb 11 17:44:11 2013
New Revision: 174919
URL: http://llvm.org/viewvc/llvm-project?rev=174919view=rev
Log:
When generating IR for default copy-constructors, copy-assignment operators,
move-constructors and move-assignment operators, use memcpy to copy adjacent
POD
Thanks John. Committed the requested changes in r174919.
Thanks to both of you for your help.
- Lang.
On Mon, Feb 11, 2013 at 11:52 AM, John McCall rjmcc...@apple.com wrote:
On Feb 8, 2013, at 12:21 AM, Lang Hames lha...@gmail.com wrote:
Thanks very much for all the help guys. I've attached
Author: lhames
Date: Mon Feb 11 18:44:43 2013
New Revision: 174925
URL: http://llvm.org/viewvc/llvm-project?rev=174925view=rev
Log:
Backing out r174919 while I investigate a self-host bug on Takumi's builder.
Modified:
cfe/trunk/lib/CodeGen/CGClass.cpp
Interesting. I'll back out the patch while I try to reproduce. Thanks
Takumi!
- Lang.
On Mon, Feb 11, 2013 at 4:33 PM, NAKAMURA Takumi geek4ci...@gmail.comwrote:
Lang, seems it broke selfhosting...
http://bb.pgr.jp/builders/clang-3stage-x86_64-linux/builds/1011
2013/2/12 Lang Hames lha
Thanks very much for all the help guys. I've attached an updated patch
incorporating your feedback. It also fixes a bug - I had been memcpying
members with defaulted but non-trivial assignment operators.
Mind if I commit?
On Thu, Feb 7, 2013 at 3:28 PM, Lang Hames lha...@gmail.com wrote
Sure thing. I'm working on an update at the moment - I'll roll this in.
Cheers,
Lang.
On Thu, Feb 7, 2013 at 3:25 PM, John McCall rjmcc...@apple.com wrote:
On Feb 5, 2013, at 6:45 PM, Richard Smith rich...@metafoo.co.uk wrote:
On Tue, Feb 5, 2013 at 5:31 PM, Lang Hames lha...@gmail.com
, Lang Hames lha...@gmail.com wrote:
Hi Richard, John,
Thanks very much for the feedback - an updated patch is in the works.
Cheers,
Lang.
On Thu, Jan 31, 2013 at 7:55 PM, John McCall rjmcc...@apple.com wrote:
On Jan 11, 2013, at 7:05 PM, Lang Hames lha...@gmail.com wrote:
At present
Hi Richard, John,
Thanks very much for the feedback - an updated patch is in the works.
Cheers,
Lang.
On Thu, Jan 31, 2013 at 7:55 PM, John McCall rjmcc...@apple.com wrote:
On Jan 11, 2013, at 7:05 PM, Lang Hames lha...@gmail.com wrote:
At present, if a class contains any Non-POD members
Ping.
On Mon, Jan 14, 2013 at 10:35 AM, Lang Hames lha...@gmail.com wrote:
I think this applies equally to default move operators, I just hadn't done
enough homework to be sure yet.
- Lang.
On Fri, Jan 11, 2013 at 7:20 PM, Richard Smith rich...@metafoo.co.ukwrote:
On Fri, Jan 11, 2013
I think this applies equally to default move operators, I just hadn't done
enough homework to be sure yet.
- Lang.
On Fri, Jan 11, 2013 at 7:20 PM, Richard Smith rich...@metafoo.co.ukwrote:
On Fri, Jan 11, 2013 at 7:05 PM, Lang Hames lha...@gmail.com wrote:
At present, if a class contains
At present, if a class contains any Non-POD members we perform element-wise
copies for each field when generating the implicit copy-constructor and
implicit copy-assignment operator (with an optimization for array members).
This patch changes this behavior - adjacent POD members will be memcpy'd,
Blaikie dblai...@gmail.com wrote:
On Wed, Nov 14, 2012 at 11:51 PM, Lang Hames lha...@gmail.com wrote:
Author: lhames
Date: Thu Nov 15 01:51:26 2012
New Revision: 168027
URL: http://llvm.org/viewvc/llvm-project?rev=168027view=rev
Log:
Make -ffp-contract a codegen option, rather than
Author: lhames
Date: Thu Nov 15 01:51:26 2012
New Revision: 168027
URL: http://llvm.org/viewvc/llvm-project?rev=168027view=rev
Log:
Make -ffp-contract a codegen option, rather than a laguage option. This makes
more sense anyway - it determines how expressions are codegen'd. It also ensures
that
Author: lhames
Date: Sat Nov 3 17:29:05 2012
New Revision: 167363
URL: http://llvm.org/viewvc/llvm-project?rev=167363view=rev
Log:
Support interleaving of other pragmas with FP_CONTRACT at the beginning of a
compound statement.
Modified:
cfe/trunk/include/clang/Parse/Parser.h
Thanks John,
Committed, with support for other pragma annotation tokens as well, in
r167363.
Cheers,
Lang.
On Thu, Nov 1, 2012 at 12:51 PM, John McCall rjmcc...@apple.com wrote:
On Oct 25, 2012, at 1:39 PM, Lang Hames wrote:
Tim Northover pointed out that there's a flaw in my recent
Author: lhames
Date: Sun Nov 4 00:08:08 2012
New Revision: 167369
URL: http://llvm.org/viewvc/llvm-project?rev=167369view=rev
Log:
Test case for r167363.
Modified:
cfe/trunk/test/Parser/pragma-fp-contract.c
Modified: cfe/trunk/test/Parser/pragma-fp-contract.c
URL:
:29 PM, Lang Hames lha...@gmail.com wrote:
Author: lhames
Date: Sat Nov 3 17:29:05 2012
New Revision: 167363
URL: http://llvm.org/viewvc/llvm-project?rev=167363view=rev
Log:
Support interleaving of other pragmas with FP_CONTRACT at the beginning
of a
compound statement.
Modified
Ping.
On Thu, Oct 25, 2012 at 1:39 PM, Lang Hames lha...@gmail.com wrote:
Hi All,
Tim Northover pointed out that there's a flaw in my recent FP_CONTRACT
patch (r166383). That patch restricted FP_CONTRACT (or rather
tok::annot_pragma_fp_contract) to appearing as the first token
Hi All,
Tim Northover pointed out that there's a flaw in my recent FP_CONTRACT
patch (r166383). That patch restricted FP_CONTRACT (or rather
tok::annot_pragma_fp_contract) to appearing as the first token in a
compound statement. The problem with my patch is that it prohibits things
like:
void
Hi Tim,
Yes - this is definitely overly conservative. I'll fix it up.
Thanks for catching this.
- Lang.
On Wed, Oct 24, 2012 at 4:28 AM, Tim Northover t.p.northo...@gmail.comwrote:
Hi Lang,
I think this check is ever-so-slightly too strict. Currently it
disallows the following code:
Author: lhames
Date: Sun Oct 21 14:56:13 2012
New Revision: 166400
URL: http://llvm.org/viewvc/llvm-project?rev=166400view=rev
Log:
Fix typo, make test case slightly more reabable. Thanks to Dmitri Gribenko for
the suggestions.
Modified:
cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
Thanks for the feedback. Fixed in r166400.
On Sun, Oct 21, 2012 at 2:37 AM, Dmitri Gribenko griboz...@gmail.comwrote:
Hi Lang,
On Sun, Oct 21, 2012 at 4:10 AM, Lang Hames lha...@gmail.com wrote:
Author: lhames
Date: Sat Oct 20 20:10:01 2012
New Revision: 166383
URL: http://llvm.org
Author: lhames
Date: Sat Oct 20 20:10:01 2012
New Revision: 166383
URL: http://llvm.org/viewvc/llvm-project?rev=166383view=rev
Log:
When used in a compound expression FP_CONTRACT should proceed all explicit
declarations and statements. Emit an error if the FP_CONTRACT is used
later in a compound
Thanks Doug,
Patch applied with a few additional comments in r164989.
Cheers,
Lang.
On Mon, Oct 1, 2012 at 3:07 PM, Douglas Gregor dgre...@apple.com wrote:
On Oct 1, 2012, at 3:02 PM, Lang Hames lha...@gmail.com wrote:
Hi Doug,
I've attached a new patch with your suggestions included
Hi Jim,
I wanted to verify target data strings during bitcode/asm parsing. I think
the logical place for TargetData verification is in TargetData itself, but
it would violate layering to have VMCore depend on that. Instead VMCore has
it's own hacky target-data string parsers (see for instance
Hi All,
This patch adds support for the FP_CONTRACT pragma to clang. It adds a bit
to BinaryOperator and CXXOperatorCallExpr to track the FP_CONTRACT pragma
state as each AST node is constructed. Pragma state is made to follow scope
correctly by having an RAII object save and restore the state
this gets
pattern-matched into a single instruction).
-Hal
On Wed, 26 Sep 2012 17:12:50 -0700
Lang Hames lha...@gmail.com wrote:
Hi All,
This patch adds support for the FP_CONTRACT pragma to clang. It adds
a bit to BinaryOperator and CXXOperatorCallExpr to track the
FP_CONTRACT pragma
Hi All,
My reading of C99 TC3, 6.5.8 is that setting FP_CONTRACT to OFF should
disallow all contractions. When -ffp-contract=fast the FP_CONTRACT setting
is ignored, so that would break with the spec (usual caveat, howover: I'm
not a language lawyer, so take this with a grain of salt). As for
time in the coming weeks.
Cheers,
Lang.
On Tue, Jul 24, 2012 at 1:05 PM, Tobias Grosser tob...@grosser.es wrote:
On 05/30/2012 05:41 AM, Lang Hames wrote:
Hi All,
I guess it's better to CC both lists, rather than have parallel feedback
on these patches - so for the Clang people who haven't
Author: lhames
Date: Thu Jul 5 19:59:19 2012
New Revision: 159794
URL: http://llvm.org/viewvc/llvm-project?rev=159794view=rev
Log:
Add -ffp-contract = { fast | on | off } command line option support.
This flag sets the 'fp-contract' mode, which controls the formation of fused
floating point
regard for indentation:
def ffp_contract: Joined'-ffp-contract=, Groupf_Group,
Flags[CC1Option], HelpText
.;
On Mon, Jul 2, 2012 at 2:43 PM, Lang Hames lha...@gmail.com wrote:
Hi All,
The attached patch adds a -ffp-contract=style option which (mostly)
follows
Author: lhames
Date: Thu Jul 5 20:10:46 2012
New Revision: 159796
URL: http://llvm.org/viewvc/llvm-project?rev=159796view=rev
Log:
Forgot to rename one use of FPContractModeTy
Modified:
cfe/trunk/include/clang/Basic/LangOptions.def
Modified: cfe/trunk/include/clang/Basic/LangOptions.def
Hi All,
The attached patch adds a -ffp-contract=style option which (mostly)
follows the behavior of GCC's option. Styles are 'fast', for aggressive FMA
formation, 'on' for FP_CONTRACT compliance, and 'off' for no FMA formation
(in the future this might be relaxed to FMA formation in cases where
Do you not see an attached patch? That's bizarre - gmail shows it attached
in my sent messages.
Attaching again just in case.
- Lang.
On Mon, Jul 2, 2012 at 4:52 PM, Meador Inge mead...@codesourcery.comwrote:
Attaching the patch might help the review ;-)
On Jul 2, 2012, at 4:43 PM, Lang
Hi All,
This patch adds support for gcc's -fexcess-precision flag to clang. I'm new
to clang's option handling. Could somebody please sanity check it for me?
Cheers,
Lang.
fexcess-precision.patch
Description: Binary data
___
cfe-commits mailing list
Hi Steve, Chandler, Hal,
That said, I don't love overloading excess-precision for this, even if fma
is formally a special case of excess precision, mostly because excess
precision has even more bizarre corner cases -- it leads to such
monstrosities as cos(x) != cos(x).
Sounds like
Hi Hal,
I object to 'never' because there may be cases in the future where we
can determine that extra precision cannot change the result so we can
use fma while maintaining strict standard compliance. 'strict' is much
better.
That's two votes for 'strict'. I'm happy with that. :)
For an
Hey,
My point is that we *just* changed the name a few days ago. Now is the
prime time to change it in light of the present discussion.
Yep - I'll rename the LLVM flag for consistency with the frontend version.
- Lang.
___
cfe-commits mailing list
.
On Wed, May 30, 2012 at 11:14 AM, Matthieu Monrocq
matthieu.monr...@gmail.com wrote:
On Wed, May 30, 2012 at 9:20 AM, Lang Hames lha...@gmail.com wrote:
Agreed - Legal was a poor choice of terms. I don't know if we want to
check TLI.isOperationLegal(...) though - an llvm.fma.* call (which
wrote:
On May 31, 2012, at 7:22 PM, Lang Hames wrote:
Thanks for the suggestion Matthieu. I spoke to Doug and he recommended
using attributes rather than a FunctionDecl bit to represent the
fp_contract state.
Hmm. I had suggested a bit on FunctionDecl on the assumption that this
would often
Agreed - Legal was a poor choice of terms. I don't know if we want to
check TLI.isOperationLegal(...) though - an llvm.fma.* call (which is what
we lower to) will always be legal...
Owen pointed out that I'm finding new and interesting ways to abuse the
term 'legal' here. To clarify: If
Hi All,
I guess it's better to CC both lists, rather than have parallel feedback on
these patches - so for the Clang people who haven't seen this yet:
I want to improve Clang/LLVM's support for the fp_contract pragma.
(Background: when the fp_contract pragma is ON, multiplications and
additions
Hi Stephen,
the llvm.fmuladd.* intrinsic is itself a guarantee that the fused
expression would be legal. This should simply say ... that the fused
expression would be efficient.
I meant 'legal' in the sense that the target architecture has a fused
multiply-add instruction, since clang will
Hi Evan,
Right, the comment should not talk about legal. The code in
SelectionDAGBuilder.cpp should check TLI.isOperationLegal(ISD::FMA, ty) in
addition to isFMACheap(). We don't want to combine two checks in one.
Agreed - Legal was a poor choice of terms. I don't know if we want to check
Author: lhames
Date: Sun May 27 16:39:49 2012
New Revision: 157547
URL: http://llvm.org/viewvc/llvm-project?rev=157547view=rev
Log:
Fix call to APSInt constructor - it doesn't take an initial value, just a
bitwidth and signedness. Also rename the variable to reflect its purpose.
No test case -
Author: lhames
Date: Thu Dec 8 13:26:24 2011
New Revision: 146169
URL: http://llvm.org/viewvc/llvm-project?rev=146169view=rev
Log:
Added missing testcase from r145849. Thanks to Dave Blaikie for catching this.
Added:
cfe/trunk/test/SemaCXX/warn-func-as-bool.cpp
Added:
Very cool. Thanks Dave!
On Thu, Dec 8, 2011 at 7:43 PM, David Blaikie dblai...@gmail.com wrote:
Just adding some finishing touches to Lang's recent excursion into the
front end by adding notes to describe how to suppress (and in simple cases,
fix) the warning
Nice catch. Thanks Richard!
- Lang.
On Dec 5, 2011, at 8:48 PM, Richard Trieu wrote:
Author: rtrieu
Date: Mon Dec 5 22:48:01 2011
New Revision: 145918
URL: http://llvm.org/viewvc/llvm-project?rev=145918view=rev
Log:
Switch a cast to a dyn_cast and check the pointer before using. Fixes
Author: lhames
Date: Mon Dec 5 14:16:26 2011
New Revision: 145845
URL: http://llvm.org/viewvc/llvm-project?rev=145845view=rev
Log:
Make isWeakDecl available as a method on ValueDecl.
Modified:
cfe/trunk/include/clang/AST/Decl.h
cfe/trunk/lib/AST/ExprConstant.cpp
Modified:
Author: lhames
Date: Mon Dec 5 14:49:50 2011
New Revision: 145849
URL: http://llvm.org/viewvc/llvm-project?rev=145849view=rev
Log:
Add a warning for implicit conversion from function literals (and static
methods) to bool. E.g.
void foo() {}
if (f) { ... // - Warns here.
}
Only applies to
Thanks for the feedback Doug and Richard. Committed (with feedback
incorporated) in r145845 and r145849.
- Lang.
On Sat, Dec 3, 2011 at 12:40 PM, Douglas Gregor dgre...@apple.com wrote:
On Dec 1, 2011, at 7:22 PM, Lang Hames wrote:
Oops - left my test case out of the previous patch
...@google.com wrote:
On Mon, Nov 28, 2011 at 1:38 PM, Lang Hames lha...@gmail.com wrote:
This patch adds a warning for implicit conversion from functions to
booleans.
Could someone take a look and let me know if anything needs fixing or
improving?
Cheers,
Lang
Oops - left my test case out of the previous patch.
- Lang.
On Thu, Dec 1, 2011 at 7:16 PM, Lang Hames lha...@gmail.com wrote:
Hi Richard,
I've added source ranges to the diagnostic, however I'm wary of catching
cases like
if (foo) {}
That seems too deliberate. For now I'd prefer
Author: lhames
Date: Wed Nov 30 17:03:25 2011
New Revision: 145534
URL: http://llvm.org/viewvc/llvm-project?rev=145534view=rev
Log:
Test case for fix committed in r145441.
Modified:
cfe/trunk/test/Index/complete-recovery.m
Modified: cfe/trunk/test/Index/complete-recovery.m
URL:
Good idea. Committed in r145534.
- Lang.
On Tue, Nov 29, 2011 at 8:24 PM, Nico Weber tha...@chromium.org wrote:
Test case? :-)
On Tue, Nov 29, 2011 at 2:37 PM, Lang Hames lha...@gmail.com wrote:
Author: lhames
Date: Tue Nov 29 16:37:13 2011
New Revision: 145441
URL: http://llvm.org
Author: lhames
Date: Tue Nov 29 16:37:13 2011
New Revision: 145441
URL: http://llvm.org/viewvc/llvm-project?rev=145441view=rev
Log:
Test isaFunctionDecl to exclude objective-C methods. This ensures the
following cast will never fail.
Modified:
cfe/trunk/lib/Sema/SemaExpr.cpp
Modified:
This patch adds a warning for implicit conversion from functions to
booleans.
Could someone take a look and let me know if anything needs fixing or
improving?
Cheers,
Lang.
func-as-bool-warning.patch
Description: Binary data
___
cfe-commits mailing
Author: lhames
Date: Mon Oct 10 18:44:43 2011
New Revision: 141601
URL: http://llvm.org/viewvc/llvm-project?rev=141601view=rev
Log:
Update target data strings for ARM and X86 to include the natural stack
alignment parameter Ssize that was introduced in r141599.
Modified:
Fixed in r141617. Thanks for that Eli!
- Lang.
On Oct 10, 2011, at 5:37 PM, Eli Friedman wrote:
On Mon, Oct 10, 2011 at 4:44 PM, Lang Hames lha...@gmail.com wrote:
Author: lhames
Date: Mon Oct 10 18:44:43 2011
New Revision: 141601
URL: http://llvm.org/viewvc/llvm-project?rev=141601view
Author: lhames
Date: Mon Oct 10 19:52:51 2011
New Revision: 141617
URL: http://llvm.org/viewvc/llvm-project?rev=141617view=rev
Log:
Fixed natural stack alignment for Linux x86-32. Thanks Eli.
Modified:
cfe/trunk/lib/Basic/Targets.cpp
Modified: cfe/trunk/lib/Basic/Targets.cpp
URL:
Author: lhames
Date: Mon Oct 10 20:06:28 2011
New Revision: 141622
URL: http://llvm.org/viewvc/llvm-project?rev=141622view=rev
Log:
Added natural stack alignment to target-data.c test case.
Modified:
cfe/trunk/test/CodeGen/target-data.c
Modified: cfe/trunk/test/CodeGen/target-data.c
URL:
76 matches
Mail list logo
