Sorry I misplace this email :'( This is your output with MinGW .-
0.0
0.0
** N .F.
Ok.. On BCC and Clipper is GPF, Excell handled exception, OW and MingGW work
correctly.
I think of a start-up too MinGW environment.
>-Original Message-
>From: Xavi [mailto:jara...@gmail.com]
>Sent: Thursday, May 28, 2009 8:29 PM
>To: Harbour Project Main Developer List.
>Subject: Re: [Harbour] gcc 4.4.0 warnings
>
>Horodyski Marek (PZUZ) escribió:
>>
[ ... ]
>> On OpenWatcom it is
Horodyski Marek (PZUZ) escribió:
[ ... ]
*--
Function main()
local i, nd := 0.0, nd1 := 1.1
Cls
? nd
for i := 1 to 30
nd := nd + nd1
next
for i := 1 to 30
nd := nd - nd1
next
? nd
for i := 1 to 1
nd := nd * nd1
next
? nd, ValType( nd), nd > 0.01
return Nil
*-
Please, someone could try this with gcc 4.4.0 in Linux.
Is only for historical reasons and curiosity :)
What is the output, of course if it works?
My output in Win with 3.4.5 is .-
MinGW GNU C 3.4.5 (32-bit) => ndbRes == -0.0002 ndbRes == 0 is .F.
error: decimal floating point not sup
On Thu, 28 May 2009, Horodyski Marek (PZUZ) wrote:
Hi,
> >to reduce the compilation time (-gc3 strongly increase the time).
> >The build time with -j5 (I have 3 CPU machine) make parameters:
> -gc3 increase time or speed ?
> When time - that is compilation time or execution app ?
It increase the
> [ ... ]
>>to reduce the compilation time (-gc3 strongly increase the time).
>>The build time with -j5 (I have 3 CPU machine) make parameters:
>
>
> -gc3 increase time or speed ?
> When time - that is compilation time or execution app ?
It increases compilation time as the amount and complexity
o
>-Original Message-
>From: Przemyslaw Czerpak [mailto:dru...@acn.waw.pl]
>Sent: Wednesday, May 27, 2009 6:18 PM
>To: Harbour Project Main Developer List.
>Subject: Re: [Harbour] gcc 4.4.0 warnings
[ ... ]
>to reduce the compilation time (-gc3 strongly increase the time
>-Original Message-
>From: Mindaugas Kavaliauskas [mailto:dbto...@dbtopas.lt]
>Sent: Wednesday, May 27, 2009 3:41 PM
>To: Harbour Project Main Developer List.
>Subject: Re: [Harbour] gcc 4.4.0 warnings
>
>Hi,
>
>
>I see a few new features under GCC: hbvm
Hi,
WaitForSingleObject() works OK for a few calls, but later it says we
have data...
We are not alone. These seems to be useful:
http://www.tech-archive.net/Archive/VC/microsoft.public.vc.language/2006-07/msg00320.html
http://tech.groups.yahoo.com/group/zepp/message/819
This fixes the code:
Hi,
Why I do need to stuff GTSTD with keyboard events, to make application
work?
Probably there is sth wrong with this code:
#elif defined( HB_IO_WIN )
if( !pGTSTD->fStdinConsole ||
WaitForSingleObject( ( HANDLE ) hb_fsGetOsHandle( pGTSTD->hStdin ), 0
) == 0x )
On Wed, 27 May 2009, Mindaugas Kavaliauskas wrote:
Hi,
> Your exe is still a little bit smaller. Maybe just because of different GT.
It also effect the size but not only. See below.
> Why I do need to stuff GTSTD with keyboard events, to make application
> work?
Probably there is sth wrong w
One more time:
speedtst_bcc_gc2.exe 64.97 / 68.08
speedtst_gcc_gc2_strip.exe 55.44 / 56.44 (old .exe, no -l option)
speedtst_bcc_gc3.exe 68.13 / 71.20
...
Should be:
speedtst_bcc_gc2.exe 64.97 / 68.08
speedtst_gcc_gc2_strip.exe 55.44 / 56.44
speedtst_bcc_
Hi,
I do not think it's a fair test condition for your executables by
flooding it with [Enter], but here are the times:
C:\harbour\__tst__>spd-bcc-gc2.exe 64.44 / 67.44
C:\harbour\__tst__>spd-mgw-gc2.exe 53.03 / 55.47
C:\harbour\__tst__>spd-mgw-gc2-Os.exe65.92 / 69.02
and my:
On Wed, 27 May 2009, Mindaugas Kavaliauskas wrote:
> Yes, I've received. But I can not test it. It do nothing (0% CPU usage) if
> I do not keep [Enter] key pressed. If I keep [Enter] pressed, tests are
> performed. The same for all 3 your executables. This made me think about
> some gt problems.
Xavi wrote:
I don't have test this version. Have you tried to -Os and linker with -s?
It's like I get better results in size with 3.4.5
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
What parameters are you using for compiler speedtest?
I have not tried or used any options/parame
Sorry to jump into.
I do not know what happens but it seems that the mail is deferred. :)
Wow! I did not expect to be such a big difference in exe size (496KB vs 882KB) if different optimisation is used.
--
Xavi
___
Harbour mailing list
Harbour@harb
Hi,
Thank you, binaries in attachment sent to your private mail.
Please inform me if you received them.
Yes, I've received. But I can not test it. It do nothing (0% CPU usage)
if I do not keep [Enter] key pressed. If I keep [Enter] pressed, tests
are performed. The same for all 3 your execu
On Wed, 27 May 2009, Mindaugas Kavaliauskas wrote:
Hi,
>> But then I created windows binaries of speedtst.exe for both compilers
>> also compiled with -gc2:
>>1) BCC:
>> size:600576
>> execution time: 33.38 / 33.60
>>2) MinGW:
>> size:882688 (stripe
Mindaugas,
I don't have test this version. Have you tried to -Os and linker with -s?
It's like I get better results in size with 3.4.5
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
What parameters are you using for compiler speedtest?
Xavi
Mindaugas Kavaliauskas escribió:
Hi
Hi,
But then I created windows binaries of speedtst.exe for both compilers
also compiled with -gc2:
1) BCC:
size:600576
execution time: 33.38 / 33.60
2) MinGW:
size:882688 (striped)
execution time: 21.99 / 22.15
So BCC gives ~50 worse
On Wed, 27 May 2009, Mindaugas Kavaliauskas wrote:
> I see a few new features under GCC: hbvmall, I see a new discussions about
> HB_STRICT_ALIGNMENT, etc. So, I decided to do some new speed tests BCC vs
> GCC. BCC was winning long time ago (before dlmalloc).
> Test conditions:
> - SVN 11150
> -
I did an attempt with HB_USER_CFLAGS=-DHB_ALLOC_ALIGNMENT=8,
but couldn't replicate the slightly better results with
HB_STRICT_ALIGNMENT (I've rerun this one too to be sure).
Results were similar to default build.
No idea what could be the explanation, maybe my CFLAGS
were not properly interprete
Test conditions:
- SVN 11150
- WinXP SP2
- default build + -DHB_FM_STATISTICS_OFF
-DHB_FM_STATISTICS_OFF is the default now.
- speedtest.exe
BCC MinGW 4.4.0
Test execution69.58 / 73.9057.77 / 59.98
speedtst.exe size622592 1090648 (903680 stripped
Hi,
I see a few new features under GCC: hbvmall, I see a new discussions
about HB_STRICT_ALIGNMENT, etc. So, I decided to do some new speed tests
BCC vs GCC. BCC was winning long time ago (before dlmalloc).
Test conditions:
- SVN 11150
- WinXP SP2
- default build + -DHB_FM_STATISTICS_OFF
- s
On Wed, 27 May 2009, Szak�ts Viktor wrote:
> 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
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
Hi
>I hope we can fix it, because this line isn't safe.
>Is it need at all?
Yes. As this value is used in HB_AX_SHUTDOWNCONNECTIONPOINT().
I will think other means.
>The easiest fix is to initialize them on declaration
>with some default values.
Oh, ok, will do in a while.
Regards
Pritpal Bed
../../wvgsink.c: In function 'HB_FUN_HB_AX_SETUPCONNECTIONPOINT':
../../wvgsink.c:516: warning: dereferencing pointer 'hSink.33' does
break strict-aliasing rules
Have no idea how to cast it.
I hope we can fix it, because this line isn't safe.
Is it need at all?
../../wvgsink.c:546: note: in
Hello
Viktor Szakáts wrote:
>
> ../../wvgsink.c: In function 'HB_FUN_HB_AX_SETUPCONNECTIONPOINT':
> ../../wvgsink.c:516: warning: dereferencing pointer 'hSink.33' does
> break strict-aliasing rules
>
Have no idea how to cast it.
> ../../wvgsink.c:546: note: initialized from here
> ../../wv
Hi Pritpal,
I'm getting these remaining warnings when compiled with GCC 4.4.0
(with HB_STRICT_ALIGMNENT):
---
../../wvgsink.c: In function 'HB_FUN_HB_AX_SETUPCONNECTIONPOINT':
../../wvgsink.c:516: warning: dereferencing pointer 'hSink.33' does
break strict-aliasing rules
../../wvgsink.c:546: note
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
Thanks. What should we do in default builds? Can we safely
pacify the warnings while keeping performance? Should we just
safely suppress these warnings?
Brgds,
Viktor
On Mon, May 25, 2009 at 9:56 PM, Przemyslaw Czerpak wrote:
> On Fri, 22 May 2009, Szak�ts Viktor wrote:
>
> Hi,
>
>
>> FYI, other
On Fri, 22 May 2009, Szak�ts Viktor wrote:
Hi,
> FYI, otherwise the build process went smoothly, I'll make some speed
> tests later:
> ../../binnum.c:115: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
[...]
All of above warnings are hacks introduced in x86 builds
FYI, otherwise the build process went smoothly, I'll make some speed
tests later:
../../binnum.c:115: warning: dereferencing type-punned pointer will
break strict-aliasing rules
../../binnum.c:123: warning: dereferencing type-punned pointer will
break strict-aliasing rules
../../binnumx.c:85: warn
34 matches
Mail list logo