Sender: root AT delorie DOT com
Message-ID: <37A0B878.29E06A84@inti.gov.ar>
Date: Thu, 29 Jul 1999 17:24:24 -0300
From: salvador <salvador AT inti DOT gov DOT ar>
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 <eliz AT is DOT elta DOT co DOT il>, 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<djgpp_last_ctor-djgpp_first_ctor; i+=4)
    djgpp_first_ctor[i]();
-----
  for (i=3; i<djgpp_last_dtor-djgpp_first_dtor; i+=4)
    djgpp_first_dtor[i]();
-----

But it could fail if we have 0 constructors and at least one destructor.

SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
                    set AT ieee DOT org set-soft AT bigfoot DOT com
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013