> Assuming that the new implementation will be available in time for 4.9, my
> primary concern is that in the meanwhile running the libstdc++ testsuite will
> be quite noticeably slower. Do you have some numbers?
Just use the numbers I used the last two times I tried to explain why PCH was
> Thanks. Having the source tree available is not a problem, as I
> require it to copy the actual testsuites into the work tree. Adding
> a few more files from the source tree would not be a problem.
From:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html
You can run the tests with a co
> > Note that one of the objectives of this email is to try and get
> > maintainers from thinking there is going to be "a perfect time" to
> > switch. Development history tells us there will always be more
> > changes. We've been sitting on ABI-breaking changes since 2003.
>
> e.g. http://gcc.gnu
> My concern is specifically about options for changing the default
> language version, not options for changing the libstdc++ ABI. More
> generally, about configure options affecting the semantics of code
> passed to GCC, as opposed to non-semantic configure options such as
> choosing the proces
> > As it turns out, the mangling changes don't really impact the
> > explicit instantiations compiled in to libstdc++.so. So, it seems
> > possible to say
>
> Right, so people can use -fabi-version=0 and still use the installed
> libstdc++.
>
> > I think a compelling case could be made to ship
> I like the idea, but not very strongly. I can live with having to say
> -std=c++11 (which I do via shell functions or scripts)
Well, the actual C++11 compile/runtime environment is going to be more
than just -std=c++11. It's looking something like -std=c++11
-fabi-version=7 + versioned names
> I think that's a bad idea; having too many ways to configure things
> will cause undue confusion.
Seems like the train has already left the station WRT gcc configure
options. If you feel this is a real issue, then it could be solved the
same way that thread support was solved, by adding a "Th
> bkoz pointed out that I forgot to update invoke.texi about
> -fabi-version=6. Applying to trunk
I've been thinking about this.
As it turns out, the mangling changes don't really impact the explicit
instantiations compiled in to libstdc++.so. So, it seems possible to say
1. compile libstdc++
> I would like to report some broken links on
> http://gcc.gnu.org/onlinedocs/ Namely links to PDF version of "GCC
> 4.6.2 Standard C++ Library Reference Manual" and "GCC 4.6.2 Standard
> C++ Library Manual" referencing
> http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-manual.pdf.bz
> Whats left
> ===
> Functionality is pretty much complete, but there are a few minor lose
> ends still to deal with. They could be done after a merge, in the
> next stage, or required before... you tell me :-)
>
> - potentially implement -f[no]-inline-atomics (to never produce
> inline
Hi Diego! Sorry to have missed this talk at the GCC Summit, this work
looks interesting.
> We have created a new branch for the incremental parsing work
> that Lawrence and I described at the last GCC Summit
> (http://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=IncrementalCompile
> To the steering committee: I propose Ralf Wildenhues as a new
> maintainer for the build machinery.
>
> Ralf often has useful comments for proposed patches to the configure
> scripts. He has done good work in upgrading to new versions of
> autoconf and libtool. As an autoconf maintainer himse
> The FSF's responsibility for legal matters under the Mission
> Statement comes with a duty to the developers not to get in the way
> of the "Patches will be considered equally based on their technical
> merits." principle from the Mission Statement. The FSF is failing in
> its duty to what was
> So one way to move forward is to effectively have two manuals, one
> containing traditional user-written text (GFDL), the other containing
> generated text (GPL). If you print it out as a book, the generated
> part would just appear as an appendix to the manual, it's "mere
> aggregation".
This
> I believe that the right fix (short of simply abandoning the GFDL,
> which would be fine with me, but is presumably not going to pass
> muster with RMS) is a revision to the GPL that explicitly permits
> relicensing GPL'd content under the GFDL, by anyone. Movement in
> that direction should no
> gcc.gnu.org will be preferrable, I think. That allows a number of us
> to help out if neede, re-running scripts, etc.
Right. The Makefiles are set up for this now.
> For the time being I suggest to apply the patch below, though. What
> we have in place as of today simply is broken (and has
> What if we ask the FSF if we can dual license the constraints.md files
> under both the GPL and the GFDL?
Thanks for the update Mark.
I agree that we are likely to get more traction with a request to dual
license as opposed to re-license.
Although I confess to lingering doubts as to the big p
> In a biweekly call with the other GCC Release Managers, I was asked
> today on the status of the SC/FSF discussions re. GFDL/GPL issues. In
> particular, the question of whether or not we can use "literate
> programming" techniques to extract documentation from code and take
> bits of what is c
> I guess what we should rather do is copying over the .html files from
> the temporary directory into the web tree and then do the compressing
> in the web tree. But I assume you guys on the libstdc++ side are a
> lot more familiar with this, so it's your call.
I guess what we should rather do
> 2) The clang invocations don't need -fcaret-diagnostics
> -fshow-source-location -fdiagnostics-fixit-info because they are the
> default.
>
> 3) It's best to not pass -fdiagnostics-print-source-range-info unless
> you're looking for machine interpretable output. This flag adds
> things like {3
> How to contribute? patches against the html? I see there are some
> examples without output. Also, it would be nicer if the page linked to
> each PR in bugzilla.
Well, the html is auto-generated so that isn't really the way to go.
Should I just check in the tests + xml into some gcc repository?
Hello all!
I've put up a short diagnostics comparison between gcc, icc, and
clang. It is my plan to update this with major revisions to individual
compilers.
Included are most of the outstanding bugzilla requests with the
"diagnostic" keyword. However, I am looking for help! Please send me
cod
> Some of the support for those
> classes is in current trunk, but a crucial change to the compiler to
> allow binary compatibility between those classes and the C builtin
> types wasn't approved before the 4.5 feature cutoff (see
> http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01321.html).
Am a
> I added myself (Edward Smith-Rowland) to MAINTAINERS (Write After
> Approval).
Thanks!
Look forward to seeing more of your work, and hope that working on gcc
branches directly is helpful to you.
best,
benjamin
Why do we have a libstdc++ list? For questions like this...
> > > > FAIL: decimal/binary-arith.cc (test for excess errors)
plus
> However, the testsuite failures still occurs as follows...
>
> Executing on
> host: /sw/src/fink.build/gcc45-4.4.999-20091005/darwin_objdir/./gcc/g++
> -shared-libg
> I get the same failure for powerpc64-linux. It starts with r150641
> from Benjamin Kosnik.
Should be fixed in r150707
-benjamin
Hey Ralf! Saw your message about updating gcc/src to current auto
tools, in favor. But, it looks like the autoconf 2.64 release is not
out, last I see is 2.63b at the end of March. This and
confirmation of --with-build-sysroot working seem to be the only open
issues standing in the way of the conv
>Manually executing make in gcc44-4.3.999-20081212/darwin_objdir
> after a failed build of gcc trunk on i686-apple-darwin9 produces...
This appears to be an include ordering issue. Revision 142738 works
around this to fix the bootstrap issue (although the problem still
exists and is readily a
Hi Silvius Rus and Lixia Liu! Thanks for posting this, asking for
advice, and being willing to help improve libstdc++!
> Goal: Give performance improvement advice based on analysis of
> dynamic STL usage.
Your project sounds intriguing, and something that could potentially be
useful for GNU C++
> > Also, the parallel mode page is somewhat unclear as to exactly _how_
> > to substitute the parallel algorithms "on a piecemeal basis."
>
> Let me add the libstdc++ list where the experts are. Usually, user
> support questions should go to [EMAIL PROTECTED], not the general
> lists which is a
...expecting these documents to be put up on the gcc wiki at some point,
right? Does anybody have an ETA or know how this has worked in previous
years?
http://gcc.gnu.org/wiki
-benjamin
Thanks for reporting this. I believe these 3 errors to be fixed as of
revision 135015. Can you check?
best,
-benjamin
clude/Makefile, which looks for
> "^#undef _GLIBCXX_LONG_DOUBLE_COMPAT. Please revert it for now.
Hi Janis. I have been able to reproduce this (finally), and have
checked in the attached patch to fix it.
tested x86_64/linux
tested powerpc64/linux --with-long-double-128
-benja
> We are seeing tests posted, at least, even if the volume isn't what
> it probably should be for a primary.
sparc-solaris2.10+ has been tested twice on trunk since
stage one for gcc-4.4 opened. This is unacceptable, and in the lower
bounds even for a secondary target. (All of which have more reg
> What was the issue?
Incorrect (too-lenient) config for OpenMP in other target libraries
besides libgomp.
I reverted to the too-permissive behavior, which is still wrong but at
least won't break stuff.
This is now bugzilla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36101
-benjamin
> Please keep it as primary. I try to give my best to help out.
>
> I do daily testing on 2.8/2.10. Currently 2.8 is broken.
You do seem to be the most active solaris contributor at the moment,
and that is encouraging. Thanks for your hard work.
Any chance you could post the results of your dai
Given that the set of posted solaris test results for trunk during the
last four months barely requires two hands:
2008-01
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg01474.html
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg01460.html
http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg01460
> Doing a build of gcc from revision 134693 with
The build issue should be fixed post 134776.
-benjamin
> apparently for all single-thread targets (like cris-elf).
>
> Could it be that you forgot to actually test that this works on
> single-thread targets? Or how did you test that?
Reverted on the branch, fixing on trunk. Sorry, you are correct. I did
not test single thread targets.
-benjamin
> Also, I think the conclusion was that the compiler should not claim
> any knowledge of these types unless specifically configured for a
> particular target - that is, defaults.h should not contain any default
> definitions.
My strong preference is to just predefine:
__INT8_T__
__INT16_T__
__IN
> Some changes I have committed already or plan to commit shortly, but
> there are some where I'd appreciate some help.
Sure.
> As a consequence of the restructuring of the libstdc++ documentation,
> the following prominent links are broken. Do you have current
> replacements for these?
>
>
> I've moved ext/pb_assoc now. Looking in the libstdc++ directory,
> there are a couple of further files/directories I'm not sure about:
>
> -rw-r--r-- 1 bkoz gcc 1862 Feb 12 20:27 bk02.html
> -rw-r--r-- 1 gccadmin gcc724 Apr 12 00:55 bk02.html.gz
> -rw-r--r-- 1 bkoz gc
> > All the links your reference later in your email are actually dead
> > links, from the documentation pre-Docbook. IMHO they should not be
> > part of the libstdc++ online docs at all, but I don't know how to
> > remove them.
>
> That should happen automatically, as far as I can tell, now that
> I checked in the change to gcc-4.3/changes.html and added a comment
> to the PR about other changes we should make to the section about
> decimal floating-point support in the GCC Manual. Thanks for the
> reminder, I had planned to do this long ago and then forgot all
> about it.
Thanks, appre
> How's this?
Hey Janis! Sorry, I missed your first email.
This looks great, thanks for your quick response. Can you check this
in? I filed 35777 about this, so this may fix that PR.
thanks,
benjamin
> Index: changes.html
> ===
>
Still waiting on this...
-benjamin
HJ asked this in June 2007:
http://gcc.gnu.org/ml/gcc/2007-06/msg00144.html
It seems as if delaying the announcement was what was desired then. Is
this still the case?
I was just as surprised as HJ was to not find this documented anywhere.
I'd rather have it documented, and marked experimental
Thanks Paolo for fixing up the links as requested by Gerald.
> Working on the link consistency of the http://gcc.gnu.org, I ran into
> a couple of links on the libstdc++ side that are in need of a bit
> love. It would be great could one of you libstdc++ guys look into
> those.
All the links your
Hi HJ!
If you look at the website, it says that the paper deadline has been
extended to April 11. It also has abstracts of the accepted talks: if
you submitted a paper and it's not here:
http://www.gccsummit.org/2008/speakers.php?types=TALK
Then I think it's safe to say that it was not accepted
> last 24 hrs I get this:
>
> make[2]: Entering directory `/mnt/share/bld/gcc'
> make[3]: Entering directory `/mnt/share/bld/gcc'
> rm -f stage_current
> make[3]: Leaving directory `/mnt/share/bld/gcc'
> Comparing stages 2 and 3
> warning: ./cc1-checksum.o differs
> warning: ./cc1plus-checksum.o
last 24 hrs I get this:
make[2]: Entering directory `/mnt/share/bld/gcc'
make[3]: Entering directory `/mnt/share/bld/gcc'
rm -f stage_current
make[3]: Leaving directory `/mnt/share/bld/gcc'
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
Bootstrap
> Is there a chance of any sort of streaming audio broadcast instead of
> having to dial in?
Not for this call, sorry.
-benjamin
> Will you allow people to call in as an observer, and not a
> participater?
Yes, as long as we have enough lines for full participants.
Please note that I'll summarize this call in email afterward, so that
mechanism will also be available to lurkers.
-benjamin
Hello all!
Jason Merrill, Doug Gregor, and I invite all interested GCC hackers to
discuss implementation of the compiler and library parts of the
C++0x concepts proposals. This is to be a brainstorming session, where
we discuss the best way to complete the work, what can be taken from
existing br
> The attached patch makes it clearer to me, does anyone agree?
Please check this in. Thanks Jonathan!
-benjamin
> I would start with Dave's fix, and then see if we can improve it
> somehow. Presumably this is talking about Manuel's work, at least
> in part?
In part. Actually, the new warnings are all over the place.
I've attached a summary from:
http://sunsite.mff.cuni.cz/rawhide20071220-gcc43/Werror/
>> Of course there is a third option:
>> * Make pedwarns warnings by default unless -Werror or
>> --pedantic-errors are given (just like the C front-end).
>This makes sense to me. I have never understood why it is a good idea
>for the C++ and C frontends to differ in this way.
Me too. The curre
> Attached is a rough cut of a detailed portability document
I also put this up here temporarily:
http://people.redhat.com/~bkoz/porting_to_gcc43.html
-benjamin
Hello all.
As many know, various linux distributors are working on re-compiling
their distros with GCC mainline in the hopes of helping GCC 4.3
stabilize. As part of this effort, many bugs have been filed in GCC
bugzilla, and many portability issues have been identified.
Attached is a rough cut
> What's up?
Well, I just checked out the whole trunk again and everything is fine.
So, probably some screw-up on my end.
Sorry for the noise.
-benjamin
Getting this today on updates:
%svn update
stty: standard input: Invalid argument
stty: standard input: Invalid argument
svn: Checksum mismatch for '.svn/text-base/tree-vrp.c.svn-base';
expected: '284237c8119d7910c47b9bbee2161731', actual:
'99646b12bbb393c78836b9c1097a6cf8'
I tried a couple (dis
> I would like to give the libstdc++ maintainers a chance to comment on
> the libstdc++ patch above and Rask and other maintainers a chance to
> comment on the libgloss reversion. I'll pre-approve the patch if no
> objections in 48 hours.
This looks fine to me.
-benjamin
> (Dependencies on native or not are a bad idea. It's much better
> always to do the same thing for a GNU/Linux target - or any other
> target that can also be native - than to do things differently
> depending on whether the same target is native or cross.)
Agreed.
When we have a staged build
> if there is a rule that
> libstdc++ configure shouldn't try to link anything, it doesn't appear
> to be well enforced.
The rule is that libstdc++ shouldn't do link tests unless it knows it
is native. Not "libstdc++ configure shouldn't try to link anything."
This means that there is a huge bias
> >> I think I prefer Richard's suggestion of not branching until we're
> >> ready to make the .0 release. The effect should be the same
> >> except that people don't have to deal with checking patches in on
> >> the branch vs. the trunk until after 4.3.0 goes out.
> >>
> >
> > I like this a
> I think I prefer Richard's suggestion of not branching until we're
> ready to make the .0 release. The effect should be the same except
> that people don't have to deal with checking patches in on the branch
> vs. the trunk until after 4.3.0 goes out.
This would certainly make things easier. A
> The only problem, is that anyone doing stage 1 work is already doing
> so in a branch, and history (at least as I remember it :-) is that
> if little johnny doesn't have a pressing need for the current
> release, he will simply keep plugging along on his branch until stage
> 1 happens, whether
> I'd rather take the make the dot-zero release approach while branching
> and count on interested people fixing bugs on the branch after the
> dot-zero release. This way if nobody is interested on a particular
> release series then we can declare the dot-zero release final -
> otherwise we'd do
FYI this was libstdc++/33682, and was fixed with:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00415.html
Which was checked in yesterday. Please update your sources and try again.
best,
-benjamin
>:8390:operands given don't match any known 386 instruction
>:8491:operands given don't match any known 386 instruction
>make[3]: *** [unwind-dw2_s.o] Error 1
>make[2]: *** [all-stage1-target-libgcc] Error 2
>make[1]: *** [stage1-bubble] Error 2
>make: *** [all] Error 2
You could configure with --
> I have not been able to get a clean libstdc++ build on ppc64 for more
> than a month (since 2007-08-23). The failure is always the same.
> While building libstdc++/system-error.cc, I get:
>
> /home/dnovillo/perf/sbox/gcc/local.ppc64/src/libstdc++-v3/src/system_error.cc:67:
> error: std::system
>> It has not yet been decided what to do about files that are part of
>> run-time libraries and are covered by GPL/LGPL + exception.
>> Therefore, no changes to
>I find this truncated sentence to be slightly ominous as I believe
>there is only one plausible choice for those files: we must convert
The "current" situation was "the best" compromise we arrived at in the
very old days of GCC-3.x.x -- see the archive for discussions.
Indeed. I would resist change just for change's sake, especially when
we have not seen a detailed bug report filed.
I'd suspect that nowadays we have better way
And also error when I add "-g"
Excellent, thanks for the feedback. I believe that the modified
configure test will solve this issue, and will be monitoring
gcc-testresults for confirmation.
best,
benjamin
Weird. Does -std=c++0x or -std=gnu++0x make a difference?
I'm trying to figure out why I see this warning/error for things like
17_intro/headers/all_c++200x_compatibility.cc
but not always.
-benjamin
This is actually a useful warning, since -ffunction-sections not only
affects debugging but also adds unnecessary size to executables on
PE-COFF targets (and others where ld does not support --gc-sections).
One way to avoid is to add --enable-cxx-flags='-fno-function-sections
-fno-data-sections
Hey. I'm looking at some of the new fails on cygwin and AIX. Both of
these platforms have fails that don't happen on linux. These fails
look like:
cc1plus: warnings being treated as errors
/cygdrive/e/gnu/gcc-4.3-20070511/libstdc++-v3/testsuite/17_intro/headers/all_c++200x_compatibility.cc:1:
er
>> Names in anonymous namespaces had external linkage for a long time in
>> G++. Did they have internal linkage in 4.1, or was that introduced
>> (in
>> theory) for 4.2?
>It was introduced in 4.2.
Whoops. It looks like this:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00449.html
http://gcc.g
> 10) Eric Christopher reported that Tom Tromey (who was not present)
> had suggested a new mascot for gcc: a unicorn with rainbows. This
>was met with general approval, and Eric suggested that everybody
>e-mail Tom with their comments. I personally would like to see
>the drawing
> if not for the real compiler as such, what advantages would i get on
> using newer glibc, libstdc++ ?? would these features be tied to
> some kernel version linux-2.4 vs 2.6 ( something like thread
> support).
Let's step back a bit.
If you look at this page:
http://gcc.gnu.org/releases.html
> I don't have these around, and I mistakenly updated my tree, so the
> numbers below are, unfortunately, incomparable to the numbers above.
> The disturbing fact is that mainline seems to be significantly slower
> now than it was in my previous tests (from just a few days ago), and
> the slowdown
4.0 branched with critical flaws that were not noticed until 4.2.0 which
is why we end up with the missed optimiation regression in the first place.
So the question is do we want to correct the regressions or not, because
right now we sound like we don't. Which regression is more important?
Wr
> > That said, I think it would not be bad to put 4.3 in stage3 mode until
> > dataflow branch is ready and, at that point, rebranch 4.2 and soon
> > after that merge dataflow branch.
FWIW I agree with Vlad and Paolo Bonzini.
It seems as if 4.2 was branched with critical flaws (it happens, no
bi
/Volumes/mrs5/net/gcc/libstdc++-v3/include/precompiled/extc++.h:43:29:
error: ext/enc_filebuf.h: No such file or directory
This was removed from the libstdc++ sources erroneously, and I just
re-added it. It should appear in your sources, if they are up-to-date,
in include/ext/enc_filebuf.h.
May I respectfully point out that the gcc make process already has
hard-coded hackery to work around the limitations of certain machines,
oses, non-GNU makes, linkers, and assembers, etc? (The thing that comes
to mind is the 42 item limit for make rules on AIX: see
libstdc++-v3/include/Makefi
> Shouldn't the
> libstdc++ configure script use the new GCC when checking things with
> AC_TRY_COMPILE.
Yes.
-benjamin
Gaby says:
> I believe we do care for good diagnostic purposes.
Yes. Diagnostics are very important. Please let's not regress on this
point. In a perfect world we'd get the diagnostic advantages of
concepts with the ability to configure typedefs.
Mike says:
> As for warning/error messages, I'd
> I think that is a splendid idea. But I don't recall having access to that
> directory. Or is it something anyone with svn write access can do?
I believe it is something that anybody could do. If you have questions,
you can ask on overseers or ping one of the overseers on IRC.
> The docs re
Hey Kaveh.
I'm trying to do a build of gcc. As documented here:
http://gcc.gnu.org/install/prerequisites.html
Apparently a specific version of GMP and MPFR are suggested. Any chance you
could upload this to ftp.gcc.gnu.org/pub/infrastructure? I've found the GMP
website to be quite unresponsiv
> Why do you need this? For installed-compiler testing, the compiler
> already searches the obvious places. (I'm not trying to be cute: I'm
> genuinely curious.)
This is needed if you need to find the C++ includes, but are not using
the C++ compiler.
> I agree that it would be nice if -print
> but in the meantime, I'm wondering if there is a much easier way to go
> about this that I'm currently overlooking.
...instead I will rip off comp_base_dir from libgloss.exp.
-benjamin
For testing outside of the build directory, it would be convenient to
have $SUBJECT.
This could be used in conjunction with -dumpversion to create
on-the-fly include and library directory paths for C++ includes in a
sane manner, much like the following:
%g++ -print-install-prefix
/mnt/share/bld
> Another, technical, reason to consider the s390x to be a primary
> platform is that it is a different 64-bit big-endian target.
>
> I always watch the test-result outcomes for gfortran of s390x closely -
> it's too easy to mess things up using little-endian.
Same here. In C++ land it also has m
> XPASS: 21_strings/basic_string/element_access/char/21674.cc execution test
> XPASS: 21_strings/basic_string/element_access/wchar_t/21674.cc execution test
>
> in the libstdc++ testsuite. From what I see in bugzilla for PR21674, it
> seems that it should be fixed on gcc trunk, right? Shouldn't t
(on-list reply to off-list followup, author stripped by request)
> [Off list]
>
> Doesn't the compiler itself also have to be originally built with thread
> support (one of the magic configure flags)?
Yes. Many of the targets for gcc default to thread support, such as
some of the BSD's and linu
> SEH: System call: ose_mutex_lock
> SEH: Error: A pointer to an uninitialized mutex (at 0x00b27988) was presented
> to
> the kernSEH: Information about current process "core_supervisor"
> SEH: Pid 0x0001000b bid 0x00010008 progpid 0x
> SEH: Callstack backtrace:
> SEH: FrameAddress Retur
moment.
:(
-benjamin
2006-09-04 Benjamin Kosnik <[EMAIL PROTECTED]>
PR c++/28871
* include/ext/bitmap_allocator.h: Add comment for end of anonymous
namespace.
* include/ext/rope: Same.
* include/bits/cpp_type_traits.h: Same.
* include/tr1
2, so I'd like to get the
correct signatures in with their introduction, and not have to patch
this up later.
?
tested x86/linux
abi tested x86/linux
-benjamin
2006-08-30 Benjamin Kosnik <[EMAIL PROTECTED]>
Richard Guenther <[EMAIL PROTECTED]>
This is now in bugzilla as:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28871
-benjamin
Hey y'all. I'm just getting back from vacation and as I re-build my
testing baselines, I've noticed a huge compilation time regression.
This happened sometime post Aug 1, 2006. Anybody else notice?
Some of this was also measured more formally on the CSiBE website:
http://www.csibe.org/ctx-full.ph
1 - 100 of 131 matches
Mail list logo
