From mint-bounce@lists.fishpool.fi Thu Mar 27 05:32:17 2008 X-Virus-Scanned: amavisd-new at demon.co.uk Subject: Re: [MiNT] Some comments on GCC 4 From: Alan Hourihane To: "J. F. Lemaire" Cc: mint In-Reply-To: <200803270951.11111.jflemaire@skynet.be> References: <200803270951.11111.jflemaire@skynet.be> Content-Type: text/plain Date: Thu, 27 Mar 2008 09:23:54 +0000 Message-Id: <1206609834.27157.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: alanh@fairlite.demon.co.uk Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: On Thu, 2008-03-27 at 09:51 +0100, J. F. Lemaire wrote: > Hello, > > With the help of MiKRO I installed GCC 4.2.3 on my Falcon and compiled > the CVS mintlib. I then went along to compile my own project (GEM > MiNTnet client) and I would like to share a few thoughts on the > process/result. > > - the file 'unistd.h' from CVS mintlib caused literally hundreds of > errors, starting from line 461 (I haven't taken note of which ones > though). I moved the file and copied over the one from the latest > official mintlib and the errors went away; I would think you may not be including something before unistd which may be required in your circumstance. Without seeing the errors I can't say, but CVS mintlib unistd.h is fine. > - the folder ../include/sys has been replaced by ../include/bits in CVS. > Is this normal? You should still have include/sys, as well as include/bits. Not sure why you are saying ../ > - the -s option given to GCC does not seem to result in stripping the > binaries. Seems to work fine here, are you sure your application hasn't already been stripped with the strip command ? > - the memory consumption of my program has increased from ca.340 KB to > ca.400. Are you looking at the file size ? as memory consumption shouldn't change. If it's file size that's probably because of optimization. You could try -Os instead of -O2 which would reduce the file size. > - the only new warning I had (which may or may not mean that my code is > clean...) was 'dereferencing type-punned pointer will break > strict-aliasing rules' on the following line: > > Col = (OBJC_COLORWORD *)&Tree[object].ob_spec.tedinfo->te_color; > > If I understand correctly, GCC 4 does not like the cast. Is there > another way to get the colour index of an object than via a cast to > OBJC_COLORWORD? That's a bug in your application, and you can use union's to fix this type of problem. Alan.