What happened to the Emscripten branch?

[angros47]

At this point, I suspect the bug is in Emscripten, not in FreeBasic

[caseih]

In your minimum code, arr is one element short. It should be:

Code: Select all

int arr[14];

Otherwise you're running off the end of the array, just as adeyblue says.

Does that change the outcome?

[angros47]

No, it doesn't.

This code works:

Code: Select all

int main(){
	int arr[14];
	for (int i=0;i<=5;i++){
		*(int*)(((int)(int*)arr + (-i << (2 & 31))) + 52) = i;
	}
}

This code fails:

Code: Select all

int arr[14];
int main(){
	for (int i=0;i<=5;i++){
		*(int*)(((int)(int*)arr + (-i << (2 & 31))) + 52) = i;
	}
}

[angros47]

On the other hand, this seems to work:

Code: Select all

int arr[14];
int main(){
	for (int i=0;i<=5;i++){
		*(int*)(((long long int)(int*)arr + (-i << (2 & 31))) + 52) = i;
	}
}

In case, maybe I figured where the issue might be: pointers, in Emscripten version of FreeBasic, were cast as 32 bit integers, since this was the standard for Emscripten. Perhaps they started using 64 bit pointers

[caseih]

Perhaps a simple C program that prints out the sizeof(int*) would tell you. I can't get any definitive answer out of google.

ChatGPT says:
"The bit size of a pointer in emscripten depends on the target architecture. By default, emscripten uses a 32-bit architecture. However, there is a MEMORY64 mode that allows for 64-bit function pointers."

[angros47]

Now I do not remember... is there a flag to force FreeBasic to compile in 32 or in 64 bit mode (emitting different .c code) without changing the platform?

[angros47]

Perhaps a simple C program that prints out the sizeof(int*) would tell you. I can't get any definitive answer out of google.

It states 4 bytes... weird. Even more confusing

[angros47]

I have also opened an issue here:

https://github.com/emscripten-core/emsc ... sues/20325

[angros47]

Could there be an error in the conversion to Emscripten code?

Ok, I found a possible workaround:

Add the option -Wl "-s WASM=0" to the command line

So:

Code: Select all

fbc -target js-asmjs mancala.bas -Wl "-s ASYNCIFY=1" -Wl "-s WASM=0" -Wl --preload-file,res

It won't produce WASM code, but only JavaScript code. It seems to work fine, in that way. At this point, I would say it is an Emscripten bug

[VANYA]

Ok, I found a possible workaround:

Add the option -Wl "-s WASM=0" to the command line

So:

Code: Select all

fbc -target js-asmjs mancala.bas -Wl "-s ASYNCIFY=1" -Wl "-s WASM=0" -Wl --preload-file,res

It won't produce WASM code, but only JavaScript code. It seems to work fine, in that way. At this point, I would say it is an Emscripten bug

Yes, this solves this local problem, but there is another one. A recursion exception occurs. Browser Console Message (Developer Tools):

Uncaught InternalError: too much recursion

This did not happen before and everything worked correctly. Here I compiled in 2020: https://users.freebasic-portal.de/freeb ... ncala.html.

It's a pity that that compiler has not been preserved.

[VANYA]

It turns out that I saved the previous compiler (1.08) in my archives. And there are no problems with him. Here is the difference in code generation:

1.09:

Code: Select all

fb_IntToStr( (int32)*(int8*)(((int64)(struct $8TMANCALA*)BDIMMANCALA$ + (-(int64)I$2 * 49ll)) + 637ll) );

1.08:

Code: Select all

fb_IntToStr( (int32)*(int8*)(((uint8*)BDIMMANCALA$ + (-I$2 * 49)) + 637) );

So the problem is in the FB compiler.

[VANYA]

For this source file:

Code: Select all

Dim shared As long bDimMancala(13)


Sub DrawNumbers()

	For i As Long = 0 To 5
		
		bDimMancala(13 - i) = i
		
	next

End Sub

DrawNumbers()

Generated code 1.08:

Code: Select all

typedef   signed char       int8;
typedef unsigned char      uint8;
typedef   signed short      int16;
typedef unsigned short     uint16;
typedef   signed int        int32;
typedef unsigned int       uint32;
typedef   signed long long  int64;
typedef unsigned long long uint64;
typedef struct { char *data; int32 len; int32 size; } FBSTRING;
typedef int8 boolean;
void fb_Init( int32, uint8**, int32 );
void fb_End( int32 );
void DRAWNUMBERS( void );
static int32 BDIMMANCALA$[14];

void DRAWNUMBERS( void )
{
	label$2:;
	{
		int32 I$2;
		I$2 = 0;
		label$7:;
		{
			*(int32*)(((uint8*)BDIMMANCALA$ + (-I$2 << (2 & 31))) + 52) = I$2;
		}
		label$5:;
		I$2 = I$2 + 1;
		label$4:;
		if( I$2 <= 5 ) goto label$7;
		label$6:;
	}
	label$3:;
}

int32 main( int32 __FB_ARGC__$0, char** __FB_ARGV__$0 )
{
	int32 fb$result$0;
	__builtin_memset( &fb$result$0, 0, 4 );
	fb_Init( __FB_ARGC__$0, (uint8**)__FB_ARGV__$0, 0 );
	label$0:;
	DRAWNUMBERS(  );
	label$1:;
	fb_End( 0 );
	return fb$result$0;
}

The difference is only in one line:

1.09:

Code: Select all

*(int32*)(((int32)(int32*)BDIMMANCALA$ + (-I$2 << (2 & 31))) + 52) = I$2;

1.08:

Code: Select all

*(int32*)(((uint8*)BDIMMANCALA$ + (-I$2 << (2 & 31))) + 52) = I$2;

[angros47]

Interesting... it might be related with another bug of the last version, that produces warning with some C functions like printf

[angros47]

The difference is only in one line:

1.09:

Code: Select all

*(int32*)(((int32)(int32*)BDIMMANCALA$ + (-I$2 << (2 & 31))) + 52) = I$2;

1.08:

Code: Select all

*(int32*)(((uint8*)BDIMMANCALA$ + (-I$2 << (2 & 31))) + 52) = I$2;

Actually, both codes should be valid: in one, the pointer is cast to a byte pointer (so, pointer math will be at one byte level: a longer pointer will increase/decrease by as many bytes as a single element is long), in the newer code it's cast to an integer, that, not being subject to pointer math rules, will act like a byte pointer

BTW, the fact that it works by disabling the WASM emitter proves that the code itself is valid, the Emscripten emitter is the cause of the issue.

[VANYA]

With this version of the compiler everything goes without problems:

https://disk.yandex.ru/d/Y8T52dgOt-vybw

P.S. I used Linux x86-64