--- Comment #2 from pcarlini at suse dot de 2006-08-15 12:17 ---
(In reply to comment #1)
What host are you working on? If that host usual editors or debuggers cannot
cope with tabs the installed headers could be sanitized by a script... Also
tabs are all 8 spaces, so I wonder what
--- Comment #5 from pcarlini at suse dot de 2006-08-16 21:21 ---
Thanks Jason!
--
pcarlini at suse dot de changed:
What|Removed |Added
CC|paolo at gcc
--- Comment #1 from pcarlini at suse dot de 2006-08-17 01:07 ---
Fixed already for gcc4.0.0 with the below: time to update your compiler, the
3.4.x branch is old and not maintained anymore...
2004-10-06 Paolo Carlini [EMAIL PROTECTED]
* include/std/std_sstream.h (_M_sync
--- Comment #10 from pcarlini at suse dot de 2006-08-17 18:40 ---
Don't worry, the problem will be *certainly* resolved in time for the release:
the issue is clear, we know in detail what's going wrong and how to fix it.
Benjamin will.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #1 from pcarlini at suse dot de 2006-08-18 02:13 ---
Hi Ian. Please go ahead with the inlining: only, from a stylistical point of
view, please move the entire body inline, do not mark inline the out of line
code. Patch preapproved, thanks a lot!
--
pcarlini at suse dot
--- Comment #3 from pcarlini at suse dot de 2006-08-18 08:31 ---
Ok, I see... Then I will do the change, a little embarassing ;) By the way, if
it's not obvious, the reason we don't simply call _M_set_length is the other
base class, where clear cannot be trivial (due to refcounting
--- Comment #6 from pcarlini at suse dot de 2006-08-18 15:44 ---
Fixed for 4.1.2.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from pcarlini at suse dot de 2006-08-25 08:08 ---
(In reply to comment #11)
Hmm, the test in GLIBCXX_ENABLE_ATOMIC_BUILTINS seems simple enough (testing
for __sync_fetch_and_add support) that the compiler should provide it as a
preprocessor symbol.
Yes, and a patch
--- Comment #2 from pcarlini at suse dot de 2006-08-25 10:05 ---
Thanks a lot, I think we can certainly apply the patch. Are you willing to
check how are we doing in the tr1::unordered_ containers? I suspect there is
the same opportunity for improvement and frankly, at this point, we
--- Comment #5 from pcarlini at suse dot de 2006-08-25 10:21 ---
Indeed, I was about to post similar considerations: in tr1::unordered_ the
table starts from *2* and I think it's fine. I'm not so happy about changing
now the table of the legacy ext containers, minimally maintained
--- Comment #7 from pcarlini at suse dot de 2006-08-25 10:36 ---
(In reply to comment #6)
Sure, up to you, but I'd say you'd still be pretty safe adding two smaller
starting hash sizes.
Then, let's go with the minimal fix. Really, we decided time ago to only
minimally maintain those
--- Comment #8 from pcarlini at suse dot de 2006-08-25 11:04 ---
The minimal fix is not correct: the implementation of find assumes a number of
buckets 0, try:
hash_setint hs(0);
hs.find(1);
it leads to a float exception. Sorry, we are not going to do anything for this
issue
--- Comment #5 from pcarlini at suse dot de 2006-08-25 17:18 ---
I'm looking a bit into this: one puzzling thing is that the corresponding leak
as reported by valgrind amounts to *zero* bytes... It may well be that
something is wrong in the testing machinery / internal leak detection
--- Comment #2 from pcarlini at suse dot de 2006-08-27 15:23 ---
Fixed. In case, we can always add something more specific for the _S_lockfree
base (in any case gets already testing on every ia64, powerpc, alpha, s390...).
--
pcarlini at suse dot de changed:
What
--- Comment #14 from pcarlini at suse dot de 2006-08-28 09:58 ---
(In reply to comment #13)
The real issue is: code independent from the atomicity model. The only way
to have this is to not inline the atomic helper functions in atomicity.h. I am
willing to revert that part of my
--- Comment #15 from pcarlini at suse dot de 2006-08-28 10:02 ---
(In reply to comment #14)
Sorry about my crazy english today, I'm concentrated on something else...
Unfortunately, for targets like ?386 and Sparc I'm afraid it's the only
option, at the moment. For ia64, powerpc
--- Comment #8 from pcarlini at suse dot de 2006-08-31 18:08 ---
Now I know how to fix it...
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo
--- Comment #10 from pcarlini at suse dot de 2006-09-02 08:34 ---
Fixed for 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from pcarlini at suse dot de 2006-09-06 17:11 ---
I think this difference is ultimately due to the existenxce of a separate *_O0
version of tree_lower_complex, in tree-complex.c. Rth added it (as part of
fixing 20610), I believe the generic version is right (-0), and I'm
--- Comment #3 from pcarlini at suse dot de 2006-09-06 17:11 ---
I think we can confirm it.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status
--- Comment #4 from pcarlini at suse dot de 2006-09-06 18:43 ---
But this issue should be recategorized, is about lowering and optimization of
complex numbers, maybe Andrew can help about that?
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #7 from pcarlini at suse dot de 2006-09-06 20:23 ---
Both the front-ends deal with 0 * -1 in the same way, the result is -0 (just
try). Anyway, the issue is crazy, a reduced pure C testcase (in principle
identical to what the complexdouble class does) behaves exactly
--- Comment #9 from pcarlini at suse dot de 2006-09-06 20:59 ---
(In reply to comment #8)
This is PR 24581 after all then.
I don't know, I'm afraid there is even more to it :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28408
--- Comment #10 from pcarlini at suse dot de 2006-09-07 00:44 ---
I'm re-reading the various floating-point standards and Annexes and I think
this issue may turn out to be a not-a-bug. Whether those standards make sense
it's another matter ;) So, what I'm reading: C99, F.8.2 says that 0
--- Comment #12 from pcarlini at suse dot de 2006-09-07 01:33 ---
(In reply to comment #11)
F.8 is *illustrative* of transformations that are *not* permitted. It
doesn't permit anything.
Where do you read that in F.8.2 ?!? I read:
0 * x - 0.0The expressions 0 * x and 0.0
--- Comment #13 from pcarlini at suse dot de 2006-09-07 01:51 ---
And, by the way, it's also generally untrue that F8 is only illustrative of not
permitted transformations. For example, a few lines above:
1 * x and x / 1 - x The expressions 1 * x, x / 1 and x are equivalent
--- Comment #16 from pcarlini at suse dot de 2006-09-07 02:04 ---
(In reply to comment #15)
Such statements also are informative, not normative. The normative
requirements come from F.3 (the operations shall be the IEC 60559
operations) and IEC 60559.
If you have IEC 60559
--- Comment #18 from pcarlini at suse dot de 2006-09-07 02:47 ---
(In reply to comment #17)
It is true that Appendix F has normative in the section title, but
F.8 starts out with
... in any case, the IEC 60559 entry in C99status reads Broken ;) ;)
--
http://gcc.gnu.org/bugzilla
--- Comment #19 from pcarlini at suse dot de 2006-09-07 09:11 ---
A side note, maybe not completely obvious to everyone and clarifying the
relationship to 24581. I understand that:
(+0) + (-0) = +0
therefore, when in the expansion of the complex product one of the two terms
--- Comment #6 from pcarlini at suse dot de 2006-09-12 08:28 ---
Basing on Martin' comments, I think this PR should bu suspended, waiting for
the outcome of DR 309 (certainly directly relevant).
--
pcarlini at suse dot de changed:
What|Removed
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW |SUSPENDED
Summary|std::basic_istream::sentry|[DR 309
--- Comment #1 from pcarlini at suse dot de 2006-09-12 15:08 ---
*** This bug has been marked as a duplicate of 9042 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2006-09-12 15:08 ---
*** Bug 29035 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from pcarlini at suse dot de 2006-09-12 15:10 ---
To be 100% sure, we checked again gcc4.1.1 both on x86-linux and powerc-darwin
and the bug is definitely not there (anymore)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29035
--- Comment #4 from pcarlini at suse dot de 2006-09-12 15:41 ---
(In reply to comment #3)
Where should I look at?
I don't understand what are you looking for, really. Your snippet behaves in
the correct way, per the Standard which we are implementing. Also, to repeat,
the issue
--- Comment #3 from pcarlini at suse dot de 2006-09-12 15:50 ---
Then the real issue maybe is the following: what are we going to do vs C++0x
features? Shall we set-up the compiler switch for it (-std=c++0x?) and start
adding things? Or people believe it's too early? Maybe a good
--- Comment #1 from pcarlini at suse dot de 2006-09-12 16:30 ---
Let's think a bit more about this issue, without forgetting, however, that our
default (*) string class is *reference counted*: that means that upon s1=s2 the
string s2 is *not* actually copied, only the reference count
--- Comment #6 from pcarlini at suse dot de 2006-09-12 16:33 ---
(In reply to comment #5)
(In reply to comment #4)
Shouldn't the output be:
6
azerty123
9
In case, that would be a separate issue, we never considered implementing that
behavior. It would be easy, of course. I
--- Comment #7 from pcarlini at suse dot de 2006-09-12 16:55 ---
(In reply to comment #6)
(In reply to comment #5)
(In reply to comment #4)
Shouldn't the output be:
6
azerty123
9
In case, that would be a separate issue, we never considered implementing that
behavior
--- Comment #3 from pcarlini at suse dot de 2006-09-12 17:31 ---
Yes, I understand. But consider another scenario were, after the initial
assignment, you are not adding anything more later on (in the loop, in your
case): doing a shallow copy (changing only the reference count) means
--- Comment #9 from pcarlini at suse dot de 2006-09-12 17:33 ---
(In reply to comment #8)
Sorry for the noise.
Your feedback is always welcome, really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29035
--- Comment #4 from pcarlini at suse dot de 2006-09-12 17:38 ---
If it's not sufficiently obvious: a reserve on cacheKey *after*
cacheKey=current.FileName; much better only after having checked that the
vector is not empty, would be exactly as effective as the c_str workaround (as
usual
--- Comment #6 from pcarlini at suse dot de 2006-09-12 20:18 ---
(In reply to comment #5)
Why would this be faster ?
Just try...
The resize() happend only once at the beginning, before the iteration starts.
And even with the reserve(), the reserve() would happen everytime before
--- Comment #6 from pcarlini at suse dot de 2006-09-12 20:30 ---
For the record, personally and for what is worth my personal opinion in the
compiler area, I have nothing against adding to the compiler -std=c++0x and
start adding things, in general. I'm also finding a little adventurous
--- Comment #8 from pcarlini at suse dot de 2006-09-12 20:45 ---
(In reply to comment #7)
...
problematic are string assigns, not += and you are moving the reserve
*after* the assign.
Yes, but in the every assign the capacity would still be lost. This would mean
the reserve
--- Comment #10 from pcarlini at suse dot de 2006-09-12 21:01 ---
(In reply to comment #9)
I see this point too, I have been thinking about something along those
lines, but you understand that we have an ABI, which we *must* keep
absolutely stable,
Yes, I understand
--- Comment #2 from pcarlini at suse dot de 2006-09-13 16:51 ---
As a matter of fact valarray *always* undefines the macros, besides in those
two specific cases (and the first one is even undefined weren't for a typo ;)
So, we can as well do the two-lines change...
--
pcarlini
--- Comment #1 from pcarlini at suse dot de 2006-09-14 11:14 ---
In order to catch this kind of run-time problem you want debug-mode: just
recompile your code with -D_GLIBCXX_DEBUG.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2006-09-18 09:20 ---
Fixed for 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #2 from pcarlini at suse dot de 2006-09-18 23:26 ---
(In reply to comment #1)
And what does the C++ standard say about this case?
As far as I can see, the standard is very vague about the relationship between
the two max_size. About allocator::max_size, it says the largest
--- Comment #4 from pcarlini at suse dot de 2006-09-20 10:09 ---
(In reply to comment #3)
Actually, I think deque could do with a better max_size.
It's not at all clear to me what we can possibly do in the general case of
discontiguous containers. Certainly, we don't want Segmentation
--- Comment #6 from pcarlini at suse dot de 2006-09-20 10:22 ---
(In reply to comment #5)
The reason I bought this up here, is because I thought (and I could be wrong,
sorry) that the overflow was being caused by the fact that we allow the
container size to get too big, and if we
--- Comment #7 from pcarlini at suse dot de 2006-09-20 10:45 ---
... and in fact, even for vector, I think we can only reasonably provide a
time-independent upper-bound, because in general we cannot know how much memory
each element' constructor is going to allocate... No, I'm more
--- Comment #9 from pcarlini at suse dot de 2006-09-20 15:00 ---
(In reply to comment #8)
I agree also we can't do any better. On 64 bit systems it will be even harder
to give anything sensible.
I'm only wondering whether it would make sense to divide by sizeof(T) also in
the other
--- Comment #10 from pcarlini at suse dot de 2006-09-20 15:57 ---
(In reply to comment #9)
I'm only wondering whether it would make sense to divide by sizeof(T) also in
the other containers beside vector: the upper bound would be somewhat tighter
and still correct, AFAICS. What do
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org
--- Comment #12 from pcarlini at suse dot de 2006-09-21 00:13 ---
Fixed for 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #14 from pcarlini at suse dot de 2006-09-21 09:13 ---
(In reply to comment #13)
I like this solution a lot. NICE!
It seems as if everything is now consistent except for std::string. Any
thoughts on that one?
basic_string is delicate, from many different points of view
--- Comment #16 from pcarlini at suse dot de 2006-09-21 10:22 ---
(In reply to comment #15)
Ok, seems sane enough. Just curious about the omission.
I'm going to adjust vstring first. Hopefully we can back port something to
basic_string, but really seems tricky (_S_max_size is static
--- Comment #1 from pcarlini at suse dot de 2006-09-22 11:19 ---
The first bug simply doesn't exist given the comment at the beginning of
__pool_base. The second one is at most a documentation issue: _M_chunk_size
shall be always much bigger than _M_max_bytes, thus __block_count always
--- Comment #3 from pcarlini at suse dot de 2006-09-22 13:42 ---
(In reply to comment #2)
would it not be easier to do a post increment and not have a problem with
people never reading documentation? especially considering that it's so easy
to
fix?
No, for the simple reason
--- Comment #5 from pcarlini at suse dot de 2006-09-22 14:48 ---
(In reply to comment #4)
ok, perhaps this is not really a bug, however segfault is not very user
friendly. could ASSERT solve it?
No, we don't have asserts anywhere, for various reasons. Really, the
documentation must
--- Comment #8 from pcarlini at suse dot de 2006-09-25 10:07 ---
Fixed for 4.1.2.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #11 from pcarlini at suse dot de 2006-09-25 13:00 ---
(In reply to comment #10)
We should have -std=c++2003 and -std=c++0x. However, care must be
exercise about what is included in both options.
-- Gaby
So what will -ansi -pedantic-errors use? c++98, 2003, or 0x
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #1 from pcarlini at suse dot de 2006-09-25 21:55 ---
Thanks Howard.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from pcarlini at suse dot de 2006-09-25 21:58 ---
Working on it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #4 from pcarlini at suse dot de 2006-09-26 01:01 ---
Fixed for 4.1.2.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #40 from pcarlini at suse dot de 2006-09-26 15:57 ---
(In reply to comment #38)
We have our reasons to enable strict aliasing by default.
In my opinion, this is a central point. I think we should try to explain what
strict aliasing buys from the point of view
--- Comment #4 from pcarlini at suse dot de 2006-09-27 07:39 ---
Fixed for 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #21 from pcarlini at suse dot de 2006-09-27 08:07 ---
(In reply to comment #20)
First of all, the problem is that bad that even 1*z != z when *no*
optimisation is requested.
Yes :(
Secondly, could somebody clarify how patch
http://gcc.gnu.org/ml/gcc-patches/2005-02
--- Comment #3 from pcarlini at suse dot de 2006-09-29 14:29 ---
Hi Richard. For sure, I'm missing many details here, having to do with alias
analysis, but I'm puzzled anyway ;) I mean, the current libsupc++
implementation of placement new is:
// Default placement versions of operator
--- Comment #5 from pcarlini at suse dot de 2006-09-29 14:52 ---
(In reply to comment #4)
One way to paper over the problem is to move std::new out-of-line :(
Otherwise
I cannot see how we can fix this in libsupc++ without gcc help. Basically we
somehow need to insert (at least
--- Comment #8 from pcarlini at suse dot de 2006-09-29 16:08 ---
Let's suppose for a moment we actually try to fix this issue in the library: is
adding a barrier conforming to the letter of 18.4.1.3/2-3, 5-6, that is:
Returns: ptr.
Notes: Intentionally performs no other action
--- Comment #10 from pcarlini at suse dot de 2006-09-29 16:23 ---
(In reply to comment #9)
There has to be some communutation between the library and the compiler to
tell
it that the memory location is being reused as defined by 3.8 of the
standard.
Yes. But considering
--- Comment #6 from pcarlini at suse dot de 2006-10-02 20:51 ---
(In reply to comment #5)
Interesting. The vanilla EDG front end rejects it as expected. I wonder why
Intel accepts it when neither EDG nor gcc does.
Sorry about the trivial question: Intel in *strict* mode?
--
http
--- Comment #1 from pcarlini at suse dot de 2006-10-05 09:28 ---
Ok, thanks for the report. The issue is the following: tellp() calls
pubseekoff, whereas seekp() calls pubseekpos. Since we are implementing the
resolution of DR 453, which allows pubseekoff to not fail when the stream
--- Comment #4 from pcarlini at suse dot de 2006-10-06 09:59 ---
Fixed for 4.1.2 and 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org
--- Comment #6 from pcarlini at suse dot de 2006-10-06 11:14 ---
I'm reassigning to Benjamin...
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2006-10-06 11:51 ---
Fixed everywhere.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #7 from pcarlini at suse dot de 2006-10-06 16:07 ---
(In reply to comment #6)
try again.
Certainly I can confirm that the problem cannot be reproduced anymore by
tweaking the random seed to 1153519516.
the thing about (now) throw_allocator is that if some
--- Comment #1 from pcarlini at suse dot de 2006-10-07 17:03 ---
This a well known not a bug (I'm sure similar issues are discussed in the
mailing list, also user code implementing char - char conversions via iconv):
output to UTF-8 is done by wchar_t streams (thus, for example, wcout
--- Comment #2 from pcarlini at suse dot de 2006-10-07 17:28 ---
Forgot to add: after having properly switched to a wchar_t stream, we must make
sure that it actually does the conversion: the clean solution via std::codecvt
is used by default only in converting streams (file streams
--- Comment #3 from pcarlini at suse dot de 2006-10-07 19:47 ---
Reopen...
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|RESOLVED
--- Comment #4 from pcarlini at suse dot de 2006-10-07 19:48 ---
... to mark it as duplicate.
*** This bug has been marked as a duplicate of 16006 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from pcarlini at suse dot de 2006-10-07 19:48 ---
*** Bug 29379 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #9 from pcarlini at suse dot de 2006-10-08 01:24 ---
Feedback not forthcoming.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status
--- Comment #9 from pcarlini at suse dot de 2006-10-08 01:32 ---
No open issues.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #6 from pcarlini at suse dot de 2006-10-08 11:04 ---
Let's reopen this report as an enhancement request. In fact, we should
implement this:
http://gcc.gnu.org/ml/libstdc++/2004-06/msg00256.html
probably by using iconv to implement the relevant char - char codecvt_byname
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29385
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #1 from pcarlini at suse dot de 2006-10-09 21:22 ---
Undefined behavior, i.e., anything can happen: array sq has got positions 0..8
whereas d = n % 10 spans 0..9, thus the code writes beyond the end of sq.
--
pcarlini at suse dot de changed:
What|Removed
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29438
--- Comment #2 from pcarlini at suse dot de 2006-10-12 14:21 ---
Indeed, I was about to add to the audit trail that the template template
parameter is essential.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29438
--- Comment #3 from pcarlini at suse dot de 2006-10-12 14:24 ---
... and I also agree that the issue seems *very* similar to 29236.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29438
--- Comment #11 from pcarlini at suse dot de 2006-10-13 16:45 ---
Benjamin, I'm seeing these failures:
http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00654.html
http://gcc.gnu.org/ml/gcc-testresults/2006-10/msg00575.html
Are you sure the patch is ok wrt source-less (I don't
--- Comment #5 from pcarlini at suse dot de 2006-10-17 00:04 ---
Unfortunately, at the time I overlooked this comment in locale_facets.tcc:
// NB: Not especially useful. Without an ios_base object or some
// kind of locale reference, we are left clawing at the air where
--- Comment #20 from pcarlini at suse dot de 2006-10-17 09:28 ---
Gaby, any news about this issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25608
1 - 100 of 2278 matches
Mail list logo
