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


> On Thursday, February 13, 2003, at 05:59 PM, Kaveh R. Ghazi wrote:
> > I think the idea is that you'd get the info as part of the standard
> > bug report -v invocation.  I.e.
> >
> > cc1 -fpreprocessed -O2 -g -blah -blah ... -param ggc-min-heapsize=x
> >
> > and you would automatically pass it back when reproducing the bug.  If
> > we simply output the numbers with a printf then we have to teach
> > people new bug reporting and reproducing instructions cause they'd
> > have to gleen out and manually add these -param commands.
> >
> > Ok?
> 
> I think the point is that be design, 99% of the time, it won't be 
> necessary to know or have that information to reproduce a bug.  We can 
> put it in ggc-page (or where-ever) and if it really it a problem later, 
> it is possible to move it up.

But when it is we get into the situation that we might not know that that 
is the problem -- ie we run the testcase and find that it works, so the 
bug report is summarily closed (not reproducable).

> 
> Also, no, I disagree.  The current instructions should encourage the 
> submitter to submit the output of -v.  If -v shows the information, 
> then a bug reproducer/fixer can use that information, if they need it.
> 

Putting it on the interface 
1) Shows us what the values are.
2) Allows us to override them
3) Allows a scheme where any user can override them from the command line


For the last point consider someone running gcc on a heavily loaded 
multi-user machine -- in that case there may be Gigs of ram but only a few 
hundred meg available to the individual.  It's not interesting to tune the 
performance of gcc to the amount of physical RAM, but to the amount that 
is likely to be available.  At the same time we don't want gcc to try to 
guess this since that can lead to hisenbugs.

R.



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