-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 correctly executet, and on BCC (I do
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
-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: hbvmall, I see a new
discussions about
-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).
The build time
[ ... ]
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
of
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
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
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,
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
-
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
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
- WinXP
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
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ó:
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 (striped)
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
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
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
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.
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:
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
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
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 )
{
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
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
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
../../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:
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 Bedi
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
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 dru...@acn.waw.pl wrote:
On Fri, 22 May 2009, Szak�ts Viktor wrote:
Hi,
29 matches
Mail list logo
