FreeBASIC-1.06.0-Win gcc-9.1

[srvaldez]

the builds proved problematic, I recommend the official release. :-)

[deltarho[1859]]

Well done.

I tried it on a small (242 lines with include file) test comparing Numerical Recipes and PCG32II, 32-bit and 64-bit compliled and ran OK using -gen gcc -Wc -O3.

However

FBC release (exe): 32-bit 38,400 bytes, 64-bit 41,984 bytes
FB with gcc 9.1 (exe): 32-bit 309,629 bytes, 64-bit 351,381 bytes

The FB with gcc 9.1 binaries are over 8 times larger than the FBC release binaries.

So, something is going wrong.

Still, early days yet and well done again.

[srvaldez]

thanks deltarho[1859]
the executable size is indeed a concern, however I hope you keep testing it, see if any misbehavior or crash occurs, also like to know if the executable speed increases or decreases :-)
[edit]
please try different O levels as well, sometimes O3 will increase the exe in size for the sake of speed.

[marcov]

And debuginfo, make sure they are properly stripped.

[deltarho[1859]]

On performance the 64-bit was almost identical, the 32-bit FBC release was much faster than 9.1. Without any optimization the speed collapsed but was still faster than gas,

The 9.1 binaries were huge for all O levels and even without optimization.

[srvaldez]

@marcov
believe it or not, I was wondering whether or not the strip command should be included in the standalone distribution, it's possible that the absence of the strip command is the culprit.
@deltarho[1859]
let me check the dependencies of the strip command so I can post a link to it for you.

[srvaldez]

@deltarho[1859]
please add the strip command into the respective win32 and win64 folder in the bin directory, hopefully that will work.
if fbc does not invoke the strip command automatically, then do it manually and see if it works, e.g. strip myprogram.exe

[srvaldez]

@developers
in this build, the executables are not stripped automatically, even if the strip command is added to the bin directory, is there a solution?

[srvaldez]

@deltarho[1859]
the strip command is not needed, however, for some reason it's not stripped automatically, but you can pass -strip on the compile command and it will strip the exe.

[deltarho[1859]]

<big smile>

From my post above:

Code: Select all

FBC release (exe): 32-bit 38,400 bytes, 64-bit 41,984 bytes
FB with gcc 9.1 (exe): 32-bit 309,629 bytes, 64-bit 351,381 bytes

Using '-strip -gen gcc -Wc -O3' I now get

Code: Select all

FB with gcc 9.1 (exe): 32-bit 37,888 bytes, 64-bit 40,960 bytes

So, quite a bit of an improvement. <smile>

No effect on performance.

So, where does 'strip' come from, that is not mentioned in the Help file's 'Compiler Options.'?

[srvaldez]

So, where does 'strip' come from, that is not mentioned in the Help file's 'Compiler Options.'?

-strip used to be called by default, but for some reason, something changed in the recent Git repo.
you can of course see all the command options with: fbc -h

[deltarho[1859]]

you can of course see all the command options with: fbc -h

Hmm, I get ' error 81: Invalid command-line option, "-h" '.

With Encrypternet I'm getting a 6% reduction in binary size. That is not down to the strip command but simply shows that with this exe 9.1 is producing a smaller binary than 8.1, although 6% is no big deal.

I will keep testing 9.1 but it should be noted that most of my work is cryptographic and my results may not be reflected in other areas such as graphics. What we need is other members to test in their area of interest. However, in my experience programming forums tend not to have many adventurous members, which is not a criticism but an observation. What you have shown, srvaldez, is pushing the 'boat out' has not brought the roof down and the question must be asked why does gcc 5.2 seem to be carved in stone, the fbc 1.06 release was a golden opportunity to 'up the stakes'; not to version 9 but something greater than version 5.

[srvaldez]

What you have shown, srvaldez, is pushing the 'boat out' has not brought the roof down and the question must be asked why does gcc 5.2 seem to be carved in stone, the fbc 1.06 release was a golden opportunity to 'up the stakes'; not to version 9 but something greater than version 5.

I don't know the answer to that question, but it could be related to gcc's changes and compatibility issues with existing code, I know personally that a very simple 10-line library would compile OK, but when a program linked to that library there would be errors.
[edit]
perhaps fbc --help

[deltarho[1859]]

perhaps fbc --help

Interesting, the release fbc.exe does not mention the strip command but your fbc32.exe does, so that is why it is not mentioned in the Help file.

[deltarho[1859]]

but it could be related to gcc's changes and compatibility issues with existing code

OK, but if you want to recompile some legacy code then use a legacy compiler. <grin>