> 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
Hey folks. I'm going to add "visibility" as a bugzilla keyword, and
they go through and tag the appropriate entries in bugzilla with it.
Searches for these types of problems are getting pretty ungainly, and
some kind of organizing principle should/can be applied.
-benjamin
I apologize; I didn't realize that. In that case, you're right; the
current approach is just busted. It should become an --enable option,
or a hard-coded case statement, or an autoconf test that doesn't require
linking stuff.
Really? Like --enable-symvers[=style]?
http://gcc.gnu.org/onlinedoc
> I am trying to make a configure change in the libstdc++-v3 directory but
> when I run aclocal (even on an unmodified libstdc++-v3 directory from
> the top-of-tree), I get an error message. Does anyone else see this?
The current fashion for regenerating the config/make bits is to just run:
aut
> See PR 28290 (the errors) and PR 28217 (the ICE). Both were reported
> before the actual
> bootstrap issue.
Paolo's patch for 28290 is now in.
I don't know what to do about the ICE: it looks like Mike has a patch.
Temporary workaround is to configure with --disable-libstdcxx-pch.
-benjamin
> My patch to fix this isn't at all obvious that it is correct to me.
> There are no signs that it will be reviewed anytime soon,
That's because you've buried it in an SOS message about bootstrap
breaking.
Please post your patch on gcc-patches with a sane and descriptive
subject, and put also
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
This is now in bugzilla as:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28871
-benjamin
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]>
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
> 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
(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
> 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
> 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
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
> 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
> 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
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
> 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
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
> Shouldn't the
> libstdc++ configure script use the new GCC when checking things with
> AC_TRY_COMPILE.
Yes.
-benjamin
> 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
> 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 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
> >> 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
> 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
> (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
> 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
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
> 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
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
> 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
>> 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
> 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/
> The attached patch makes it clearer to me, does anyone agree?
Please check this in. Thanks Jonathan!
-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
> 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
> Is there a chance of any sort of streaming audio broadcast instead of
> having to dial in?
Not for this call, sorry.
-benjamin
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
> 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
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
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
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
Still waiting on this...
-benjamin
> 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
> ===
>
> 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
> > 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'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
> 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?
>
>
> 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
> 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
> Doing a build of gcc from revision 134693 with
The build issue should be fixed post 134776.
-benjamin
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
> 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
> 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
> 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
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
Thanks for reporting this. I believe these 3 errors to be fixed as of
revision 135015. Can you check?
best,
-benjamin
...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
> > 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
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++
> 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
> 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
> 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 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
> 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
> > 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
> 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
> > 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
> 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
> I'm sure there are still lots of horrible bugs, which will only be
> found with a more complete test suite. But the core functionality
> works, and at this point I think it'll improve faster in the CVS server
> than sitting on my hard disk.
Yep.
> OK to commit to mainline?
Sounds like
>From here:
http://gcc.gnu.org/ml/gcc/2005-02/msg00923.html
I so want this. I've created a bugzilla entry for this as an enhancement so
this does not get lost.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20201
-benjamin
> I'd like to know from the maintainers (or other knowledgeable people)
> which is the current situation, whether those explicit instantiations
> are still needed. I'm asking because I mean to move from v7 to mainline
> a bunch of similar testcases...
I think you should kill these bits, for a
For the record, I cannot reproduce this on linux with -O2 or -O0. If you
continue to have problems, I strongly suggest reporting this in bugzilla.
-benjamin
> What is an ETA for additional information? Am I correct in
> understanding, from your previous mail, that these problems occurred in
> 4.0.0 as well?
Hi Mark. Thanks for your patience.
I'm testing a patch that resolves the issue. I expect to have
additional details within 24 hrs, and will l
> 1. Benjamin Kosnik reports that there are ABI and/or version-symbol
> problems between 3.4.x and 4.0.x version of libstdc++, and is trying to
> sort out a solution.
I think I have found an acceptable solution for this issue.
Here is more info:
http://gcc.gnu.org/ml/gcc-patche
> Please test this version and report problems in Bugzilla, with a Cc:
> to me. I'd also appreciate explicit confirmation from a representative
> of the libstdc++ team that this version as packaged still has the
> desired behavior, just to catch any packaging snafus.
This version looks correct to
> PR 22111 is about libstdc++-v3 being built with binutils 2.15, while
> 2.15.90 or later are required by the patch.
I say we solve this instead by enabling the abi checking rule only for
those platforms that are using symbol versioning. In addition, we try
to come up with an autoconf macro that
> It is my strong preference to not do macro defines in c++config.h as
> per your last patch.
Strike this, it's incorrect. Sorry Jakub.
If doing this gets around the bad link behavior, at this point, I'm
for it. I suggest you put in a link to 22109 to your patch. Then, the
patches for 22109 and
> I get the same failure for powerpc64-linux. It starts with r150641
> from Benjamin Kosnik.
Should be fixed in r150707
-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 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
> 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
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
> 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?
> 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
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
/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.
> > 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
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
> 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
> 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
> 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
>> 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
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
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
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
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
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
>> 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
1 - 100 of 131 matches
Mail list logo
