Can't use MOD or "\" with __[U]LONGINT in -lang qb

[Aetzbarr]

Hi,

Just started using FreeBASIC 1.10.0 64 bit a few days ago (my OS is Win10 64 bit) and ran into the following problem. The following code doesn't compile (I'm using -lang qb):

dim x as __longint
x=1000
print x MOD 7

This is the error message I get:

FreeBASIC-1.10.0-winlibs-gcc-9.3.0\bin\win64\ld.exe: 1.o:fake:(.text+0x4d): undefined reference to `__moddi3'

I get similar errors when changing __longint to __ulongint and/or changing MOD to "\". Only __moddi3 in the error message changes to __umoddi3 or __divdi3 or __udivdi3.
I found the following line in the changelog (https://github.com/freebasic/fbc/blob/m ... ngelog.txt):

- Multiple run-time library symbols have been removed from the global FB namespace: __main, mcount, _monstartup, rename, __divdi3, __udivdi3, __moddi3, __umoddi3, __fixunsdfdi

Is this a bug? feature? my error? The qb dialect allows defining a variable as a long integer or unsigned long integer, so why shouldn't MOD and "\" work with it?

[coderJeff]

Is this a bug? feature? my error? The qb dialect allows defining a variable as a long integer or unsigned long integer, so why shouldn't MOD and "\" work with it?

Hi, welcome.

qb(tm) didn't support 64-bit integers so ensuring full support for __longint would be above and beyond for qb dialect and would not have been a priority for any developer.

fbc's integer type is intended to be the native sized integer for the target (32bit or 64bit). but in qb dialect integer is supposed to have 16bit size, so integer promotion rules and integer handling is all screwy on 64-bit target and qb dialect requires special handling in the compiler all over the place.

If fbc can't solve the math directly with a native sized integer, then it falls back to a run-time function - like __moddi3(). Except this function isn't defined in the 64-bit toolchain runtime (i.e. libgcc in winlibs or mingw-w64), since expectation is that a x86_64 target should be able to handle the math natively and not need special help from the run time library.

[Aetzbarr]

Thanks. Indeed, using FreeBASIC 32-bit solved the problem. Also, I just compiled a small program (simple but long mathematical calculation) in both 32-bit and 64-bit. The 32-bit exe was faster.