This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Patch: RAM-based heuristics for ggc-min-heapsize and ggc-min-expand
> From: DJ Delorie <dj@redhat.com>
>
> > My understanding is that one doesn't contribute code to "textutils".
> > Rather, the assignment is to the FSF.
>
> The assignments and disclaimers are for specific projects though (and
> often for specific subsets to those projects).
True, but once code is accepted the license says "This program is free
software; you can redistribute it and/or modify it under the terms of
the GNU General Public License". I would think it obvious that
GCC+LIBIBERTY is a "redistribution" under the GNU GPL.
But I guess we disagree, rather than belabor this...
> We'd have to ask the FSF about this one.
Ok if it'll help move things forward. Whom shall I ask?
assign@gnu.org? Or do you want to do it?
> > This consideration does present a problem. If you won't accept
> > physmem.c with a GPL then I'll have to put it directly in the gcc
> > directory. That would be a shame since I can imagine other packages
> > like binutils might someday want to use similar memory hacks to get
> > speedups depending on the size of RAM.
>
> I didn't say I was rejecting it, I said we had to consider it. Is GPL
> a problem for this file? Should we ask if it can be changed to LGPL
> now, before it becomes a time-critical issue? If we agree that GPL is
> acceptable for this file, I'm ok with that, but I'd rather discuss it
> now than find out we chose wrong later.
Well here are my thoughts: I don't foresee any need to use the LGPL.
I.e. in my efforts related to GCC I don't envision needing to link
physmem.c with any non-free software. I don't expect to need it in
any runtime libraries. So the standard GPL is fine with me.
> > Though I think he used "float" instead of "double" which might avoid
> > some of the problems you raised.
>
> Float tends to not have anough mantissa digits to losslessly hold a
> reasonable integer memory amount. Of the two, I'd choose double. It
> can normally hold integers 0..2^53-1 or so without loss.
>
> > What do you suggest? size_t? float? or leave it as originally
> > written?
>
> I'd prefer a "long long" type (say, int64_t or something) if there was
> some way to get it in there portably. Given that it's a header, we
> can't always rely on autoconf providing the checks we need. Double
> would at least be guaranteed to work properly in all cases.
Agreed. So we're going to keep it as-is then, right?
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu