[Harbour] gcc 4.4.0 warnings

[Szakáts Viktor]

Hi Przemek,

I've retested after your change, results below
(two runs each), plus attached:

new (r11148):
HB_STRICT_ALIGNMENT: 38.83/39.28, 38.89/39.36
default            : 39.72/40.14, 39.66/40.20

old (r11143/r11144):
HB_STRICT_ALIGNMENT: 38.52/39.01, 38.52/39.11
default            : 43.14/43.63, 42.92/43.66

After your change all warnings disappeared in
default mode, and performance got better with
same (little smaller) binary sizes.

Speed with HB_STRICT_ALIGNMENT is a little bit
better with the new rev (and without size growth),
so shouldn't we make it the default? if yes, on
what conditions?

Brgds,
Viktor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: results.zip
Type: application/zip
Size: 5092 bytes
Desc: not available
Url : http://lists.harbour-project.org/pipermail/harbour/attachments/20090527/934e36ce/results.zip
-------------- next part --------------


On 2009.05.27., at 3:59, Szak?ts Viktor wrote:

> Hi Przemek,
>
> With GCC 4.4.0 the binaries got a bit larger when
> using HB_STRICT_ALIGNMENT, but also measurably faster.
>
> Built with 'hbmk2 speedtst.prg' (default -gc0)
>
> HB_STRICT_ALIGNMENT: 38.25/39.11, 38.42/39.08
> default            : 43.39/44.03, 43.47/44.03
>
> Brgds,
> Viktor
>
> On 2009.05.27., at 1:13, Przemyslaw Czerpak wrote:
>
>> On Mon, 25 May 2009, Szak?ts Viktor wrote:
>>> Thanks. What should we do in default builds? Can we safely
>>> pacify the warnings while keeping performance? Should we just
>>> safely suppress these warnings?
>>
>> I'm afraid that at least in few places GCC can strip out some of our
>> code or at least change the order of some instructions and wrong  
>> binaries
>> will be created. It has to be fixed.
>> Please note that number of optimizations which use strict aliasing is
>> systematically growing up so even if I pacify the warnings for GCC4.4
>> it's possible that it won't help in GCC4.5 or newer.
>> So the only one clean solution is using code which operates on
>> bytes to create more complex numbers. It looks more complicated
>> but does not have to be much slower. It's even possible that it
>> will be faster then direct access with forced casting in some modern
>> CPUs. Some new CPUs which seems to work with wrong alignment also
>> generate exception when some complex numbers are read from memory
>> address with wrong alignment but default exception handler tries
>> to complete the operation using byte access. In such case explicit
>> byte access should be noticeable faster.
>>
>> BTW have you tried to compare speedtst results for Harbour compiled
>> with and without HB_STRICT_ALIGNMENT macro?
>> The comparison should be done for -gc2 output. In -gc3 PCODE is
>> generated only for codeblocks.
>>
>> best regards,
>> Przemek
>> _______________________________________________
>> Harbour mailing list
>> Harbour at harbour-project.org
>> http://lists.harbour-project.org/mailman/listinfo/harbour
>