Re: [MiNT] Some comments on GCC 4

["J. F. Lemaire" <jflemaire@skynet.be>]

On Thursday 27 March 2008, Alan Hourihane wrote:
> On Thu, 2008-03-27 at 09:51 +0100, J. F. Lemaire wrote:

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

It's fixed now, the problem was related to the missing 'sys' folder, see 
below.

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

It would appear there'd been a write error during install. 'sys' existed 
in 'include' but as a corrupted file. I copied manually 'sys' from the 
build directory and I have no issues now with 'unistd.h'.

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

Yes, I'm sure. If I strip it after compilation, the excutable becomes 
smaller, as expected. But the -s option has not effect here. Must be 
something wrong with my GCC build, then.

On the other hand, stripped binaries are smaller than when compiled with 
GCC 2, which is good news.

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

Not the file size, the memory consumption. The application uses more 
memory than when compiled with GCC 2.95.3 with the same compilation 
options.

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

Probably, although my limited experience does not tell me how.

Cheers,
JFL
-- 
Jean-François Lemaire