compile problem

[eddier]

My compiler doesn't recognize "-Wno-strict-aliasing"



I omited the "-Wno-strict-aliasing" in the makefile_linux so it would compile. What does this option do?



Eddie

[Lutz]

I added this option after installing on my computer Mandrake 9.2 Linux, which comes with the latest GNU CC. Whithout the option I got the following complaints:



#define UINT unsigned int;

CELL * getInteger(CELL *params, UINT * num)



int var;

getInteger(params, (UINT*)&var)  <-- WARNING



It complained about: (UNIT*)&var "strict aliasing rules violated" and I casted myself crazy trying to avoid that warning until I finally just suppressed it. Perhaps you have an idea how to get rid of this warning, I always like to have all warnings and the -pedantic option turned on.



Lutz

[nigelbrown]

I see at http://pub26.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=86.topic">http://pub26.ezboard.com/ftichessteamhq ... D=86.topic">http://pub26.ezboard.com/ftichessteamhqfrm10.showMessage?topicID=86.topic

the discussion includes these rules and, in part, observes

 Re: GCC 3.3 prerelease for TIGCC

--------------------------------------------------------------------------------

 Those are the stupid strict-aliasing rules.  I knew there was some TIGCC code breaking them. And what's the worst: while the warning is new, the fact that the optimizer might break some code you get warnings about now was already there since GCC 3.0. As for fixes:

- the quick and dirty fix is to use -Wno-strict-aliasing to get rid of the warnings

- the quick and less dirty fix is to use -fno-strict-aliasing to get rid of the warnings and of the risky optimizations

- the clean fix will be to add __attribute__((may_alias)), a new attribute in GCC 3.3, to some of the TIGCCLIB types. The structure used to define INT_HANDLER is one of them, HSYM is another one (to make sure my *(unsigned long*)&hsym hack works).



Nigel

[Lutz]

for now I will suppress the warning, when most UNIXs have switched to GCC 3.3 something more refined can be put in, as long as pointers and integers have the same byte width their optimizations will not hurt and are probably welcome.



Lutz

[eddier]

Thanks!  



I use to change the makefile to turn off either readline or termcap, I don't remember which.



I've turned on code optimization several times but I've never changed anything else in the makefile.



Maybe now is the time to switch from Mandrake 8.1 to OpenBSD. I can't keep up with all of the updates anymore, so I usually buy a CD to make all of those for me. I hate downloading a program and then spend all day downloading updates and libraries that I don't have. Then, trying to figure out which order to compile all the stuff. Thanks for using standard libraries and keeping newLisp free from all those specialized libraries.



Eddie.

[Lutz]

yes, the readline/termcap confusion happened to me too, on Mandrake 9.0 I neede readline and termcap to be linked, then in 9.1 I had to change termcap to ncurses and the readline libs where not in the standard install, on Mandrake 9.2 readline had no change but now I have gcc 3.3 with that aliasing warning.



You would think that that 1970 feature of editable commandline is a standard by now :-).



On BSD it seems to need only the readline lib, but I have only tested on FreeNSD and NetBSD, never got my hands on an OpenBSD, but they are supposed to be similar. On my ISP I run newLISP under FreeBSD still with gcc version 2.95 and everything is fine.



Lutz

[eddier]

My compiler version is 2.96.



Why do you use optimization -O2? Why not -O which makes loops faster?



I had FreeBSD and loved it, unfortunately the logic boad in my old box died. I only had a copy of Mandrake 8.1 handy when BMC bought my new machine.



An extremely OS savy friend of mine that does security for a networking company switched from installing Linux to OpenBSD for firewalls, e-mail servers, httpd servers, etc... I thought I might overkill and try it even though I will use the OS as a client.



Eddie

[Lutz]

I thought -O2 does more optimizations than -O ? will investigate ...



About BSD, they say OpenBSD is the most secure of the BSD family, NetBSD the most portable. My experience is only with FreeBSD, which seems to be the most popular and up-to-date  (which is not so important for newLISP compiles)



Lutz

[nigelbrown]

re: as long as pointers and integers have the same byte width their optimizations will not hurt



Some discussions on the optimizations suggest there may more importantly be an issue about what word boundries are used when allocating/using pointers vs integers (? that may be effected more by sizes of what is packed around them rather than their own size)

 - there was also a concern voiced that turning off warnings but not the optimizations may disable a more useful warning case down the track.

Although overall this is not a big issue I'd guess.



Nigel

[Lutz]

Yes, asssuming that the compiler is smart enough to align all functions on 32 bit word boundaries, there shouldn't be a problem, as I always make sure to have my locals aligned, to help the compiler to put stuff into registers. There are only one or two functions involved in the system where the warning gets triggered and I may be able to rewrite those with non-offending code.



That would be the best, because I could just turn on all warnings and be done with it for all gcc versions.



Lutz

[eddier]

It's hard to figure out from the man pages but I think your right about -O2. I just compiled with -O3 and -fstrength-reduce (suppose to make loops faster). Seems to work.



Eddie

[Lutz]

Got all warnings worked out on LINUX(gcc 3.3.1), but still need "-Wno-initialized" on FreeBSD where warning messages are so off, that I think its a problem with the older gcc v.2.95.3 on my ISPs FreeBSD 4.4.



-O3 on Mandrake 9.2 doubles(!) the size of the executable with a ~ 10% speed up. I will stay with -O2 adding "-fstrength-reduce" makes now difference on gcc 3.3.1 on Mandrake 9.2. So, for LINUX we now do on newLISP 7.3.17:



CFLAGS = -Wall -pedantic -c -O2 -g -DNANOSLEEP -DREADLINE -DOPSYS=1



Lutz

[eddier]

Interesting. -O3 only added 20k on gcc version 2.96.



Strangely -O and -O2 resulted in files the same size. That does not mean the programs are the same however.



When I have more time, I will look at the assembly output of the different optimizations.



Eddie

[Lutz]

yes, its pretty strange, varying from version to version and platform to platform, the latter beeing mor understandable, because of different optimization approaches on a different CPU.



Historically speaking in newLISP is was always easier to achievs speedups by tweaking the code, than by changing optimization switches. On the other hand in limiting executable size, optimization seems to do a lot more, than can be achieved with tweaking code.



When introducing PCRE into newLISP the executable size jumped up, PCRE is about 35% of the entire code in newLISP, O2 helped to bring it down again.



Some of the speedup tricks I am using:



- in many cases before I make a call to strcmp(), I compare the first character of the strinfs first. This cuts in half most case of comparing strings! In some cases when comparing againts a string constant of more than 1 or 4 bytes length I cast to Int16 or Int21 integers and copare those first.



- sometimes I check the argument of a function before caling it and then have a quicker solution i.e. i evaluateExpression()



- in one instance (regular expression compile) I cache the pattern an compile only on change.



Most of the time newLISP spends in evaluateExpression() and getCell() both routines actually have been optimized by looking into the assembly (on X86) generated by the compiler and by trial and error just moving stuff around.



Lutz