; barf about the unknown config option.
Yes; if you know how to pass arguments to SVN's invocation of ssh, you
can use that instead. I only put it in the config file because I
didn't feel like looking up the svn docs this morning.
--
Daniel Jacobowitz
CodeSourcery, LLC
en up on the wiki should help.
>
> Thanks, I will have a look. This requires an update to OpenSSH >= 4.0,
> so I cannot test that right now.
Or, use the svn protocol instead for read operations? I believe you
can do this using svn switch.
--
Daniel Jacobowitz
CodeSourcery, LLC
en't already for
your port if you aren't getting the compensation code in main.
--
Daniel Jacobowitz
CodeSourcery, LLC
questions.
If you're saying that Kean's assumptions about the incoming stack
alignment are wrong, why? What should it be?
Note, I don't know or care about the answer. I'm just annoyed at your
tone.
--
Daniel Jacobowitz
CodeSourcery, LLC
c and FSF version? And is EABI support really submitted to
> the gcc 4.1?
The difference is that it's configured for an EABI target, not an ELF
(legacy) target. Build an arm-none-eabi compiler instead of an arm-elf
compiler and it should work.
--
Daniel Jacobowitz
CodeSourcery, LLC
olves to sym1 (if
available) else sym2; but ".weakref sym1, sym2" resolves to sym2 (if
available) else zero. Also sym1 does not become an external, only a
local alias, IIRC.
--
Daniel Jacobowitz
CodeSourcery, LLC
gt;
> >
> >It is intentional.
>
> ?
>
> mrs $ ping gcc.gnu.org
> PING gcc.gnu.org (209.132.176.174): 56 data bytes
> 64 bytes from 209.132.176.174: icmp_seq=0 ttl=48 time=22.327 ms
They intentionally fixed it :-)
--
Daniel Jacobowitz
CodeSourcery, LLC
please
go read the list archives? I feel like you've missed a couple of years
of context here, including the last few times we discussed why a switch
was in order.
CVS is not working well for GCC at all.
--
Daniel Jacobowitz
CodeSourcery, LLC
er of changes (by someone else, not
by Asher); they'd need a blanket assignment, or a disclaimer for Asher
in which case he would need an individual assignment.
Beyond that you'll have to contact the assignments clerk directly.
--
Daniel Jacobowitz
CodeSourcery, LLC
ug*
Let's let it go then.
I have less faith in the value of the primary/secondary platform
distinction, and no immediate stake in whether the bug is fixed in
4.0.2, since Debian has long since given up using releases rather than
the tip of the release branches. It's still a platform that people
use.
--
Daniel Jacobowitz
CodeSourcery, LLC
lures because of this bug and it set builds back several
weeks.
Personally, I'd do a 4.0.3 based on current bits.
--
Daniel Jacobowitz
CodeSourcery, LLC
oing to
> check in these changes. Once I've done that, I'll commit the patch
> below to mention the branch in the documentation.
Hey Bernd,
Has there been any news or progress on reload-branch lately? It
removes a lot of code that I'd dearly love to see gone...
--
Daniel Jacobowitz
CodeSourcery, LLC
t there be a defined set of switches which gives standard defined
> semantics.
Except that the point I've been trying to make for the last day is that
-fshort-enums does no damage to the standard. At least for C99.
--
Daniel Jacobowitz
CodeSourcery, LLC
e difficulties using this option on GNU/Linux.)
--
Daniel Jacobowitz
CodeSourcery, LLC
On Wed, Sep 21, 2005 at 10:54:56AM -0400, Robert Dewar wrote:
> Daniel Jacobowitz wrote:
> >
> >I'm not 100% sure what #3 means for enumerators whose value does not
> >fit in the range of "int", but it's pretty clear that the
> >implementation i
e what #3 means for enumerators whose value does not
fit in the range of "int", but it's pretty clear that the
implementation is not allowed to change the type of enumerators.
--
Daniel Jacobowitz
CodeSourcery, LLC
d %d %d\n", a,b,c);
> return 0;
> }
> The option -fshort-enums has no effect and the output is same as it is
> without this option.
It's not a bug. Add sizeof(enum aa) to your printf; _that_ will be
affected by -fshort-enums. The type of the enumerators remains int.
--
Daniel Jacobowitz
CodeSourcery, LLC
this before but some targets will never
> support multiple entry points.
Which has nothing to do with Gaby's question...
--
Daniel Jacobowitz
CodeSourcery, LLC
f topic for this mailing list; please take it elsewhere.
In general this responsibility would fall to the manufacturer, not any
of their suppliers.
--
Daniel Jacobowitz
CodeSourcery, LLC
x27;d mean mostly SuSE and Red
Hat, which puts it in a different light given the people and policies
involved.
--
Daniel Jacobowitz
CodeSourcery, LLC
sed on this information.
This bit binutils, in the form of a crash in a hash function on
Solaris. I think that was pointer subtraction, rather than comparison,
however.
Perhaps someone who remembers this problem more clearly than
I do can chip in if I've gotten it totally wrong.
--
Daniel Jacobowitz
CodeSourcery, LLC
r (mostly) GNU/Linux targets. If you aren't
running a hosted kernel on your board port, then you should probably be
using newlib instead.
--
Daniel Jacobowitz
CodeSourcery, LLC
nt the format specifiers in source code. Of course,
we'll need to create a C interface for doing this, which will take some
time to do right. But we know how to do that!
--
Daniel Jacobowitz
CodeSourcery, LLC
as clever as we cross-GCC people who were
> considered being complete idiots? :-)
As one of the people who implemented this, I take offense at your
comments. If you couldn't tell.
--
Daniel Jacobowitz
CodeSourcery, LLC
s a general convention, on any platform.
(That said I don't love the @filename syntax; but it could be worse,
and it seems fairly well-known...)
--
Daniel Jacobowitz
CodeSourcery, LLC
will have a rather perplexing effect
> if such a file is compiled. Maybe that's OK.
Personally, I think that's OK. Document ./@file.
--
Daniel Jacobowitz
CodeSourcery, LLC
re was implemented back in
3.3; the behavior hasn't been _changed_ and won't be until there is
consensus.
I believe that it's still can be caught, must be rethrown, or the
program will be aborted. Someone who knows better than I may want to
confirm this.
--
Daniel Jacobowitz
CodeSourcery, LLC
n mingw.
>
> FWIW, I'm opposed to the "#!" change to MinGW. It just seems hackish to
> me, and it means that we'll pay an additional cost on all normal uses of
> pex-* on MinGW, even after the compiler is installed.
Not if it's implemented after CreatePro
On Tue, Aug 02, 2005 at 09:57:39AM -0400, Diego Novillo wrote:
> On Tue, Aug 02, 2005 at 09:39:56AM -0400, Daniel Jacobowitz wrote:
>
> > Then the alias analyzer's broken.
> >
> Broken? I'm saying that we currently get this right. I don't
> know what posit
It would be if the line were:
ptr = &((cons *)(ptr))->cdr;
which is equivalent to some offset plus ptr. But there's an extra
dereference:
ptr = &((cons *)(*ptr))->cdr;
^
As far as I can tell, this code doesn't actually violate any of the
aliasing rules. It just looks funny.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Sun, Jul 31, 2005 at 03:53:42PM +0100, Mike Hearn wrote:
> On Sun, 31 Jul 2005 00:57:49 -0400, Daniel Jacobowitz wrote:
> > You may wish to read the proceedings from this year's GCC summit, where
> > another solution was presented by some gentlemen from Intel. For various
ed to their solution in principle, AFAICT, although there
was some discussion afterwards about whether the use of strong
namespace using was really necessary. I'm afraid I don't understand
C++ well enough to explain the rest of that conversation.
May just need someone to do the work.
--
Daniel Jacobowitz
CodeSourcery, LLC
hope that makes at least a little sense.
>
> I suspect that the problem is mips specific as _gp_disp handling is mips
> specific.
Yes, you're probably right. I thought this sounded familiar, but
couldn't find any references.
--
Daniel Jacobowitz
CodeSourcery, LLC
new programs. Any alternative that allows you to
generate an undefined reference to stat is a bad alternative, because
it will call the legacy function from new code.
--
Daniel Jacobowitz
CodeSourcery, LLC
ost part but if,
> for example, you take the address of the function, use the
> actual symbol stat(). But I see that most other fixincs
> use static inline.
Huh? This paragraph conflicts with the previous one I quoted. You
don't want extern inline, because you don't want the symbol stat() to
be called - that's your whole problem.
--
Daniel Jacobowitz
CodeSourcery, LLC
to use this feature. GCC usually passes ld
> whatever path specifications it needs.
I build mingw cross toolchains with sysroots :-) That'll be affected
by this change. Of course, currently I cross-build them from
--build=i686-linux, so it doesn't affect me directly.
--
Daniel Jacobowitz
CodeSourcery, LLC
by default and avoid the need for this kind of
> system-specific behavior in the makefile?
On other systems, this makes the GCC build not relocatable at install
time. I don't know if that is true on mingw32 also, but I presume so.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Wed, Jul 20, 2005 at 10:10:03PM -0400, Christopher Faylor wrote:
> On Tue, Jul 19, 2005 at 04:21:04PM -0400, Daniel Jacobowitz wrote:
> >On Tue, Jul 19, 2005 at 04:14:04PM -0400, Christopher Faylor wrote:
> >>Ok. Given that 'cp' was an acceptable fallback in the
toolchains. Or some third party linker may load DLLs
relative to its install path.
I'd say that using cp for mingw32 is not a huge step backwards. If
someone triggers a failure case, then we can do more work on it then.
--
Daniel Jacobowitz
CodeSourcery, LLC
e change of "Library" to "Lesser" in the name.
Yes - Joe, I believe you're thinking of the latest revisions of the GPL,
which do only differ in the address. LGPL 2.0 -> 2.1 predates the move
by a while.
--
Daniel Jacobowitz
CodeSourcery, LLC
t it is a useful option to have available.
Thanks for the explanation. That makes more sense. Personally, if
you're going to do this, I don't see why you're keeping debug info for
methods; either ditch all artificial methods (including defaulted
constructors but not manually specified constructors), or ditch all
methods.
--
Daniel Jacobowitz
CodeSourcery, LLC
te
instances. That is probably what you want for stabs: have one of the
base/complete ctors, but not both.
The effect on dwarf output might be more interesting.
GDB just ignores all but one of each set in stabs anyway.
--
Daniel Jacobowitz
CodeSourcery, LLC
someone should compare the two existing
bits of documentation first, since IIRC I've seen people add to one but
not the other.
--
Daniel Jacobowitz
CodeSourcery, LLC
come up with a way to build the compiler and
libraries at different times.
--
Daniel Jacobowitz
CodeSourcery, LLC
ch over one at a time.
Somebody who cares really has to update newlib soon, though!
--
Daniel Jacobowitz
CodeSourcery, LLC
Do you mean "do mind" or "don't mind" there?
If you want to update libtool, you get to play the all-of-src-uses-it
game. I have been updating src directories to more recent autoconf
versions in the hope of getting rid of our outdated libtool someday. I
believe the only remaining holdout is newlib, but I didn't check
everything.
--
Daniel Jacobowitz
CodeSourcery, LLC
; lifetime of the statement expression?
Yes, that's correct (and the only way to do this).
--
Daniel Jacobowitz
CodeSourcery, LLC
name.
BTW, you may get more comments if all of your text is before all of the
patches; I nearly missed three quarters of your message :-)
--
Daniel Jacobowitz
CodeSourcery, LLC
. Not all of us use Microsoft compilers.
> Didn't RTH objected the last time?
You can find plenty of information about this in the archives. I
recall Stan Shebs discussing it at length.
--
Daniel Jacobowitz
CodeSourcery, LLC
[Redirecting off gdb-discuss again]
On Tue, Jun 14, 2005 at 09:12:39PM -0400, Fred Fish wrote:
> On Tuesday 14 June 2005 10:55, Daniel Jacobowitz wrote:
> > better support for inline functions, which is already on the gdb
> > roadmap
>
> Where's the roadmap? I'
ag, CODE_64BIT},
>
> but they only switch ASM encoding, not the output ELF file format as
> they are intended for stuff where you really mix 32bit and 64bit code,
> such as in the boot loader.
So, we would need different directives for this purpose. I like the
idea, though it woul
riori you'd
> decide which ones.
It'd be better to handle this in gdb than in gcc, sure. There's two
parts: better support for inline functions, which is already on the gdb
roadmap, and then some way of selecting which ones to ignore. And for
that latter, I have no idea how it should look...
--
Daniel Jacobowitz
CodeSourcery, LLC
icit, an
x86_64-linux compiler would Just Work.
Which would be nice since that's what config.guess says to build :-)
--
Daniel Jacobowitz
CodeSourcery, LLC
lue
to compile if we can not run the test. I thought we already did that,
but I appear to be mistaken.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Wed, Jun 08, 2005 at 05:05:58PM -0700, Daniel Kegel wrote:
> Daniel Jacobowitz wrote:
> >Daniel Kegel wrote:
> >>Can somebody suggest a place to start looking for
> >>why the libgcc_s.so built by crosstool's gcc-3.4 can't handle
> >>exception
ilding one and the other.
Probably some important linker feature is misdetected.
--
Daniel Jacobowitz
CodeSourcery, LLC
y do you think this?
--
Daniel Jacobowitz
CodeSourcery, LLC
ove&care; I hope we'll
be updating our local port to HEAD soon.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Tue, May 24, 2005 at 05:32:27PM -0700, Zack Weinberg wrote:
> On Tue, 2005-05-24 at 20:11 -0400, Daniel Jacobowitz wrote:
> > On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
> > > Well, if I were running the show, the 'clock' would only start running
objected to shipping two versions using the same SONAME in case we
installed the new one and it turned out to be incompatible - which
we've done.
I still haven't seen a valid objection to bumping the SONAME whenever
necessary.
--
Daniel Jacobowitz
CodeSourcery, LLC
ibstdc++.so.7 branch means that we haven't even started the clock
> running on this criterion yet.
That would be three major releases unless you're counting differently
than I am. My point was that we did preserve the soname between 3.4
and 4.0, and no one's reported trouble because of that yet - and I have
fairly high confidence that no one will.
--
Daniel Jacobowitz
CodeSourcery, LLC
C++ in GCC itself - I bring it up to caution us
> against rushing into declaring libstdc++ ABI-frozen. I'd want to see
> at least two major releases with no libstdc++ soname bump and no
> problems reported, before I had confidence we'd gotten it right.
You mean, like GCC 3.4 and GCC 4.0?
--
Daniel Jacobowitz
CodeSourcery, LLC
> hope for a permanent freeze of its soname in the near future. Thus,
> while you've discovered some interesting things by trying this, I don't
> think C++ compatibility patches should be applied now.
There is no such thing as an ABI that will never again be changed.
Designing anything at all around that assumption is just asking to be
hurt.
--
Daniel Jacobowitz
CodeSourcery, LLC
cluded in built libraries. The copy in
libgcc_s.so.1 is globally visible.
You are also misinterpreting the problem. The hidden symbol is not the
problem; libstdc++ with an undefined reference to _Unwind_GetIP, and no
dependency on libgcc_s.so.1, is the problem.
--
Daniel Jacobowitz
CodeSourcery, LLC
ot;format not a string literal, argument types not checked");
The only useful difference being that you don't have to duplicate the
string.
--
Daniel Jacobowitz
CodeSourcery, LLC
anks.
>
> Which versions qualify as "recent" above? GCC 3.4, or 4.0, or both?
Since at least 3.3.
> Is there any documentation on how the new packaging mechanism works?
It's not a new packaging mechanism and it doesn't require any
adjustment; the entire thing should Just Work.
--
Daniel Jacobowitz
CodeSourcery, LLC
nt, but can't quite tell if in fact -static has any effect
> during compilation.
I don't know of any; it was a close call on one RTOS I worked on
recently, but it turned out that nothing else was necessary. This sort
of applies to MIPS but that gets a separate option (-fno-pic
-mno-abicalls).
--
Daniel Jacobowitz
CodeSourcery, LLC
has $(prefix)/libdata? None I'm familiar with.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Wed, May 11, 2005 at 11:58:39AM -0700, Greg McGary wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
>
> > ... Or you could try telling the entire compiler to treat them as
> > registers, instead of just reload. That's likely to work as well or
> > b
t; registers. I'm still trying to understand secondary-reload well
> enough to determine if that's the mechanism I want.
Yes, that's one way to do it. Or you could try telling the entire
compiler to treat them as registers, instead of just reload. That's
likely to work as well or better.
--
Daniel Jacobowitz
CodeSourcery, LLC
ese differing series of warning messages give me confidence that
> the debugging info. is correct. Is this a gcc problem, or a gdb problem?
> (I made a few quick probes in the Bugzilla database, but couldn't find
> anything that seemed relevant to malformed debug info.)
Remove the "set complaints" line from gcc/.gdbinit to stop seeing
these.
--
Daniel Jacobowitz
CodeSourcery, LLC
quot;0")]
> > UNSPEC_NOP_EXTEND))]
> >
> > --
> > Daniel Jacobowitz
> > CodeSourcery, LLC
>
> Nope. GCC doesn't like seeing two match_operand's for op 0.
Er, yeah, correct the second 0 to a 1. The point I was making was the
"0" constraint instead of a match_dup.
--
Daniel Jacobowitz
CodeSourcery, LLC
perand has DF. Do I need to make this modeless? Or is
> there some other way to create an empty conversion instruction.
You might want to try this instead:
[(set (match_operand:DF 0 "fr_register_operand" "=f")
(unspec:DF [(match_operand:SF 0 "fr_register_operand" "0")]
UNSPEC_NOP_EXTEND))]
--
Daniel Jacobowitz
CodeSourcery, LLC
> definition of "struct foo" into the output.
Is there not even a DW_AT_declaration for struct foo? If so, it's a
bug.
--
Daniel Jacobowitz
CodeSourcery, LLC
t; from gcc, either.
No ideas without concrete examples and testcase, sorry.
--
Daniel Jacobowitz
CodeSourcery, LLC
ch would affect a non-linear blowup. Do you
think it adds any value to GCC development to shout "please think about
this problem" without any concrete suggestions?
--
Daniel Jacobowitz
CodeSourcery, LLC
consider them closer to
part of libgcc than to part of gcc proper.
--
Daniel Jacobowitz
CodeSourcery, LLC
t you're trying to say in this paragraph. Not only
can you skip building libjava, you can skip building the compilers for
any languages that you do not want to test.
--
Daniel Jacobowitz
CodeSourcery, LLC
I would expect it to be drastically faster. However this won't show up
clearly in the bootstrap. The, bar none, longest bit of the bootstrap
is building stage2; and stage1 is always built with optimization off and
(IIRC) checking on.
--
Daniel Jacobowitz
CodeSourcery, LLC
code,
> you will see that this idiom is used everywhere in dbxout.c.
I think there are already some exceptions.
Do those checks still add value over the -gstabs/-gstabs+ distinction?
--
Daniel Jacobowitz
CodeSourcery, LLC
On Mon, Apr 25, 2005 at 05:05:32PM +0200, Jeroen Scheerder wrote:
> Daniel Jacobowitz:
>
> [...]
>
> > > So obviously Sun ld doesn't have the necessary support for COMDAT groups
> > > (even with GNU ld, a quite recent version seems to be required).
> > &g
27;s configure.ac doesn't check for this, but should.
So you're using gas with the Sun linker? Yes, the configure check
definitely needs to test both as and ld.
--
Daniel Jacobowitz
CodeSourcery, LLC
readelf can help you look at the relocations, if any.
--
Daniel Jacobowitz
CodeSourcery, LLC
s anywhere near that much storage
> when running genattrtab.
>
> Whether this is a genattrtab bug or a genattrtab miscompilation is a
> question best left to those with access to this platform (i.e, I
> can't answer it).
Note that that's a total allocation, not a peak allocation. The 4GB
total isn't unlikely, with all the PPC DFAs.
--
Daniel Jacobowitz
CodeSourcery, LLC
want to join the dwarf-discuss list, where this exact same
conversation is taking place - probably about the exact same
interaction.
There have been voices on both sides, but I believe there's a narrow
majority towards allowing the current behavior.
--
Daniel Jacobowitz
CodeSourcery, LLC
RATION & OPTION2 == 0
> #warning OPTION2 unset
> #else
> #warning OPTION2 set
> #endif
That's #if (1 | 4) & (2 == 0). 2 != 0, so 5&0 == 0.
--
Daniel Jacobowitz
CodeSourcery, LLC
sed is used to separate the prologue (crti.o) and epilogue
(crtn.o) into different files.
Yes, it's a hack. It's not much different from GCC's hack in
crtstuff.c.
--
Daniel Jacobowitz
CodeSourcery, LLC
nit-at-a-time
compatible, but otherwise working) mechanism that glibc uses to generate
crti.o and crtn.o, so I can no longer build a mips64-linux toolchain using
HEAD.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Sun, Apr 17, 2005 at 07:48:53PM -0700, Gary Funck wrote:
> This usage of a null substitution came up while I was trying to use
> this form of spec. for a different switch, but the following illustrates
> the problem using the existing gcc compiler as built for Redhat Linux
> running on an SGI Al
the
most natural time to do this sort of lowering is at expand; but there's
no fundamental reason why it could not be done on trees, just before
expand, and rerun relevant tree optimizers after doing so. Same as the
issues for "long long" splitting that Roger mentioned.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Thu, Apr 14, 2005 at 09:36:59AM +0200, Bernardo Innocenti wrote:
> Daniel Jacobowitz wrote:
> > On Wed, Apr 13, 2005 at 10:10:39AM +0200, Bernardo Innocenti wrote:
> >>
> >>So it seems adding coldfire-linux is the only way
> >>to address this...
> &
-*
> > for fpgnulib.c.
>
> So it seems adding coldfire-linux is the only way
> to address this...
Why? Adding support (if it isn't already there) for something like
--with-arch=coldfire should work just as well.
--
Daniel Jacobowitz
CodeSourcery, LLC
On Tue, Apr 12, 2005 at 06:34:29PM +0200, Andi Kleen wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
>
> > On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
> >> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
> >
On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
> or so... I still lean on that crutch.
A user! Can you explain why?
--
Daniel Jacobowitz
CodeSourcery, LLC
On Sun, Apr 10, 2005 at 05:52:01PM +0200, Gabriel Dos Reis wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
>
> | On Sun, Apr 10, 2005 at 05:02:36PM +0200, Gabriel Dos Reis wrote:
> | >
> | > Hi,
> | >
> | > The following is from libibtery.h
> | &
> config.h is not HAVE_DECL_XXX, but HAVE_XXX. Therefore, it appears
> that libiberty would be misdetecting declarations -- it thinks
> something is missing, whereas in fact it is not.
>
> Am I missing something here?
Try adding an AC_CHECK_DECLS call for basename. That will d
; is it available?
Nope. Your best bet would be to turn up ulimit -c and look at a core
dump.
--
Daniel Jacobowitz
CodeSourcery, LLC
y you don't
> keep times of libstdc++v3 build times. Not sure how to check
> this, except maybe rolling back libstdc++ to March 30...
Except that would have shown up in Jim's test...
--
Daniel Jacobowitz
CodeSourcery, LLC
On Fri, Apr 08, 2005 at 10:13:38AM -0700, Joe Buck wrote:
> On Fri, Apr 08, 2005 at 09:20:47AM -0400, Daniel Jacobowitz wrote:
> > On Fri, Apr 08, 2005 at 09:05:17AM -0400, Ray Holme wrote:
> > > Many thanks to all for the lessons on how NOT to make things you don't
> &g
so I copied the SRCDIR install.sh
> in and that made the top level installs work, but the sub-sub directories
> were still looking for ../install-sh - so I copied it down another level
FYI, this is already fixed in HEAD and the 3.4 branch.
--
Daniel Jacobowitz
CodeSourcery, LLC
501 - 600 of 627 matches
Mail list logo
