Date: Thu, 27 Apr 2000 10:20:02 +0200 (WET) From: Andris Pavenis To: "Mark E." cc: djgpp-workers AT delorie DOT com Subject: Re: gcc 3.0 In-Reply-To: <3907023C.30855.3E86E3@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Wed, 26 Apr 2000, Mark E. wrote: > > > > The gcc group has announced that they're ramping up for the final gcc > > 3.0 release work. Now is the best time for the DJGPP people working > > on/with gcc to get involved in testing the DJGPP port of gcc, and > > making sure we get our patches in. (but don't be annoying ;) > > I'd like suggestions on what to do about enabling ".weak" and ".gnu.linkonce" > in gcc for C++ templates. > > There are two options. I can go with the method used by the DJGPP port which > uses the "-mbnu210" switch that enables the support. Or should it done > unconditionally so that either binutils 2.9.5.1 beta or the now promised > binutils 2.10 release are required. Since gcc 3.0 will be using a new C++ > ABI, perhaps now is a golden opportunity to make the change and do it at the > same time as other major C++ changes. > There is no problem to make it default from specs: %{!mno-bnu210:-mbnu210} No need to remove it now I think much more serious problem is garbage collector: --with-gc=page doesn't work with DJGPP as none of anonymous mmap and valloc are supported. remaining --with-gc=simple is so terribly slow that I initially thought it went into infinite looping compiling toplev.c before I enabled debugging output and saw that it is expected to end after some long time (with debugging output it took about 15 minutes to complete). You can imagine what we'll get when compiling some C++ code with heavy use of STL I did some tests with one my source file (more that 600 lines of C++ code which uses many STL classes) under Linux: gcc 2.96 20000418 invokes garbage collection 12 times and it takes totally about 5 seconds (or 12% of compilation time) (--with-gc=page) As garbage collection under DJGPP will be much more slower so I'm afraid we can expect more that an hour for garbage collection only (however my earlier DJGPP tests were with non optimized first stage binary of cc1.exe) Andris