Message-Id: Comments: Authenticated sender is From: "Salvador Eduardo Tropea (SET)" Organization: INTI To: Eli Zaretskii , djgpp AT delorie DOT com Date: Mon, 20 Apr 1998 10:15:19 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: RHIDE and pentium cc1plus References: In-reply-to: Precedence: bulk Eli Zaretskii wrote: > On Fri, 17 Apr 1998, Salvador Eduardo Tropea (SET) wrote: > > > The FACT is that gcc is sensitive to PHYSICAL memory, don't ask > > me way or how, I really don't understand the effect. For some tasks > > gcc really needs PHYSICAL memory and all the virtual memory in the > > world doesn't help a bit. > > I find this hard to believe. Neither the compiler nor the library can > distinguish between physical and virtual memory, except at levels > below `malloc'. Could you please post a program that caused the > compiler to behave this way? I can't post such a thing, isn't easy to reproduce. I even thinked that was something relating to my system, but I saw this problem in the machines of other users. The problem is normally triggered by C++ programs using huge ammounts of headers. If you have enough physical memory the problem NEVER appears. > > A good example in my system is that W95 some times eats enogh > > physical memory to make fail my compiling, under plain DOS the same > > is when RHIDE uses 2Mb more than normally (for example: too much > > editor opened and InfView with a huge info file, or debug info > > loaded in memory). > > I routinely leave Emacs to run for several days on end, doing > everything from within it, including compilations. This usually > causes it to stabilize at 20MB after a couple of days (I have several > huge files loaded into it permanently). But I have never seen a case > of compilation which failed from Emacs but worked from the DOS > prompt. All I see is some disk activity due to swapping. How much physical memory do you have in this machine? Do you compile heavy C++ code? > > I don't understand why it happends because gcc uses malloc (or I'm > > wrong in it, could it use sbrk() for something?). > > As far as I could see, gcc 2.7.2.1 only uses `sbrk' to report memory > usage. So this shouldn't be the reason. But the fragmentation of the memory could be the reason. I saw these kind of problems from the beginning. When I started to use djgpp, I was using a different computer with a different amount of RAM, with a different gcc and with a different djgpp version. But the problem was there too. I remmember that the first time I compiled RHIDE I got some "internal error" from the C++ compiler, the only way to workaround it was running the makefile from a Win3.1 DOS BOX!!! that looks VERY silly because there are less memory in this case. The problem just dissapears if you have more physical memory. Perhaps is all related to bugs in GCC 2.7.x/8.x that are sensitive to the memory layout. But the problems exists, for some strange reason gcc is sensitive to the physical free memory. I can't explain why, I can't give you an example because this will fail in some system and work in other. Most of the time the error is an "internal error" some times the compiler dies with a GPF. SET ------------------------------------ 0 -------------------------------- Visit my home page: http://set-soft.home.ml.org/ or http://www.geocities.com/SiliconValley/Vista/6552/ Salvador Eduardo Tropea (SET). (Electronics Engineer) Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org ICQ: 2951574 Address: Curapaligue 2124, Caseros, 3 de Febrero Buenos Aires, (1678), ARGENTINA TE: +(541) 759 0013