This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Patch: RAM-based heuristics for ggc-min-heapsize and ggc-min-expand


> 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).  We'd have to ask the
FSF about this one.

> 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.

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]