strange bug, FB win64

[srvaldez]

try compiling the following code with FB-win64 using the the compile command fbc -w all -Wc -O2,-mfpmath=387 test.bas
used FreeBASIC Compiler - Version 1.06.0 (09-18-2018), built for win64 (64bit)
[edit] apparently it's a bug related to using the FB that's included in WinFBE, it could be related to the merging of 32 and 64-bit versions in one folder
I have my reservations about the merging, because the path structure used in the standalone version of FB is hardcoded, if I am not mistaken.
test.bas

Code: Select all

dim as integer j
dim as single s

asm
	nop
end asm

for j=1 to 3
	s+=sqr(j)
next

if you delete the asm block then it compiles
if you change s+=sqr(j) to s+=j then it compiles
if you change s+=sqr(j) to s+=sin(j) then it compiles
if you omit the flag -mfpmath=387 then it compiles

Code: Select all

G:\WinFBE_Suite\FreeBASIC-1.06.0\fbc64 -w all -Wc -mfpmath=387,-O2 -v "test.bas" (in directory: F:\FreeBASIC Programs)
FreeBASIC Compiler - Version 1.06.0 (09-18-2018), built for win64 (64bit)
Copyright (C) 2004-2016 The FreeBASIC development team.
standalone
target:       win64, x86-64, 64bit
compiling:    test.bas -o test.c (main module)
compiling C:  G:\WinFBE_Suite\FreeBASIC-1.06.0\bin\win64\gcc.exe -m64 -march=x86-64 -S -nostdlib -nostdinc -Wall -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -Wno-main -Werror-implicit-function-declaration -O0 -fno-strict-aliasing -frounding-math -fno-math-errno -fwrapv -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -masm=intel "test.c" -o "test.asm" -mfpmath=387 -O2
during RTL pass: final
test.c: In function 'main':
test.c:40:1: internal compiler error: output_operand: invalid use of register 'frame'
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://sourceforge.net/projects/mingw-w64> for instructions.
compiling C failed: 'G:\WinFBE_Suite\FreeBASIC-1.06.0\bin\win64\gcc.exe' terminated with exit code 1
Compilation failed.

[D.J.Peters]

No problem here !

Joshy

D:\FreeBASIC>fbc64.exe -v -w all -Wc -O2,-mfpmath=387 test.bas
FreeBASIC Compiler - Version 1.06.0 (07-03-2018), built for win64 (64bit)
Copyright (C) 2004-2016 The FreeBASIC development team.
standalone
target: win64, x86-64, 64bit
compiling: test.bas -o test.c (main module)
compiling C: D:\FreeBASIC\bin\win64\gcc.exe -m64 -march=x86-64 -S -nostdlib -nostdinc -Wall -Wno-unused-label -Wno-unus
ed-function -Wno-unused-variable -Wno-unused-but-set-variable -Wno-main -Werror-implicit-function-declaration -O0 -fno-s
trict-aliasing -frounding-math -fno-math-errno -fwrapv -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-table
s -masm=intel "test.c" -o "test.asm" -O2 -mfpmath=387
assembling: D:\FreeBASIC\bin\win64\as.exe --64 --strip-local-absolute "test.asm" -o "test.o"
linking: D:\FreeBASIC\bin\win64\ld.exe -m i386pep -o "test.exe" -subsystem console "D:\FreeBASIC\lib\win64\fbextra.
x" --stack 1048576,1048576 -s -L "D:\FreeBASIC\lib\win64" -L "." "D:\FreeBASIC\lib\win64\crt2.o" "D:\FreeBASIC\lib\win64
\crtbegin.o" "D:\FreeBASIC\lib\win64\fbrt0.o" "test.o" "-(" -lfb -lgcc -lmsvcrt -lkernel32 -luser32 -lmingw32 -lmingwex
-lmoldname -lgcc_eh "-)" "D:\FreeBASIC\lib\win64\crtend.o"

[srvaldez]

thanks Joshy, I found that the problem is with the merged FB-win32 and FB-win64 that's distributed with WinFBE

[counting_pine]

Looks like it's an internal compiler error in GCC. Which version of GCC is it? If it's recent, it might be worth tracking down the bug and reporting it.

[srvaldez]

hello counting_pine
the gcc version is 4.8.2, however I think the problem is in the merging of tools because I have the exact same gcc version in another standalone version which works without problems.
Paul Squires thought that it was a good idea to merge the folders of the 32 and 64-bit versions of FreeBasic, however there are problems when invoking the gcc toolchain, it may seem to work most of the time but not always, I rather have two distinct installations.

Code: Select all

G:\WinFBE_Suite\FreeBASIC-1.06.0\bin\win64\gcc.exe --version
gcc.exe (x86_64-win32-seh, Built by MinGW-W64 project) 4.8.2

C:\dev\FreeBASIC-1.06.0-win64\bin\win64\gcc.exe --version
gcc.exe (x86_64-win32-seh, Built by MinGW-W64 project) 4.8.2

[counting_pine]

Well, the merging may have brought about the circumstances that triggered the internal compiler error, but an internal error is a genuine bug in the compiler.

Given the age of the compiler (4.8.2), and it looks like Mingw-w64 now has 6.0.0, it is probably worth upgrading GCC and seeing if the error still occurs.
You should be able to test by taking the test.c source code (which you can get with fbc -R ...), and compiling it in either GCC with the parameters given by fbc -v.

EDIT: I guess 6.0.0 is the Mingw version, its version of GCC is probably significantly later.

[PaulSquires]

The problem with the mixed gcc toolchain was discussed previously on this forum. deltarho[1859] and St_W posted a fair amount about it viewtopic.php?f=6&t=27040#p252739 and I eventually fixed it with the latest WinFBE version. Make sure you are using version 1.8.1 (October 7, 2018) version. It uses the GCC 8.1 toolchain.

[srvaldez]

@counting_pine
yes, t'time to upgrade.

thank you PaulSquires, I will get the latest version.

[deltarho[1859]]

I have been testing a function over at the MsWs thread and have been using the official FBC for both 32-bit and 64-bit, as most members use them, pointed to via WinFBE 1.81 without issue. I have just tried pointing to WinFBE's default compilers FBC 1.06/gcc 8.1 and got an ' invalid use of register 'frame' ' in 64-bit with '-gen gcc -Wc -O3'. -O2, -O1, and -OFast also failed. -Os was successful and I got a speed 3 x faster than the official FBC package. I got a 3% reduction in the binary size but I am not overly interested in that because I don't write big apps.

I am not sure what that tells us but I thought it worth mentioning.

[counting_pine]

If you can trigger an internal error in the latest version of MinGW's GCC, the developers would probably appreciate knowing about it.

We might be able to narrow it down if you can provide the FB source code, the generated C file (fbc -R), and the GCC command line (fbc -v).
(You can Pastebin or similar if the results are lengthy.)

(Definitely the exact C file would be useful, to minimise differences due to the range of versions of FBC, target platforms and possible command-line parameters, etc.)