Sender: root AT delorie DOT com Message-ID: <37A0B878.29E06A84@inti.gov.ar> Date: Thu, 29 Jul 1999 17:24:24 -0300 From: salvador Organization: INTI X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686) X-Accept-Language: es-AR, en, es MIME-Version: 1.0 To: Eli Zaretskii , djgpp-workers AT delorie DOT com Subject: Re: No more warnings... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Eli replied to Nate: >On Wed, 21 Jul 1999, Nate Eldredge wrote: >> Incidentally, one of the big changes with gcc 2.95 is that the ANSI >> aliasing rules are now strictly enforced by default. > >Do I understand correctly that compiling the library with and without >strict aliasing and comparing the resultant code would reveal the >places that could break? If so, we should probably do that once we >switch to EGCS. Just for the records: This methode is almost impossible to use for Turbo Vision. I tried compiling without strict aliasing and got 38 different files over a total of 219. I analyzed just a couple and found that gcc is *much* more cleaver when strict-aliasing is enabled (default) for operations involving chars or shorts. Basically gcc does the things like a human does: loads 16 bits values in 32 bits registers and isn't paranoic (usually does tones of silly reloads or stupid assigments to the upper nibbles). That's just one example. I got differences even in the code for constructors/destructors generated *by* gcc (in the code that handles the virtual table stuff). So differences doesn't mean the program will behave differently, in all the cases I analyzed (about 5 in 2 files) the code is smaller and faster. The examples I tried run so I think they aren't affected. Something important: I don't know if anybody mentioned it, but while doing the test I used the patched version of binutils 2.9 that aligns to 16 bytes boundaries, it *breaks* _main and exit, I solved it checking for 0 before calling the destructors/constructors to skip the filler, but I'm not sure the filler is ever 0. For constructors I just used an increment of 4 instead of 1, it didn't work for destructors because they started with a fill, but I think that's constant so we can also compute it. The following works for me: ----- for (i=0; i