32/64 bit compiler issue

[sero]

Below are two examples highlighting the problem I'm encountering. An array filled with custom information I want hard coded into the executable seems to have a limit with the 64bit compiler. That same size will compile in 32bit, however.

Test 1 works for me in both 32 and 64 bit compiler.
Test 2 works for me only in 32 bit compiler. 64 bit compiler dumps a test_2.c file.
The difference is the array size of 900.

Since 32 bit works I was able to offload the custom data onto a binary file on my hard drive. I am able to access the data this way without any problem.

Test 1

Code: Select all

dim shared as byte DATA_STUFF( 26100 ) = { _
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14, ... etc
}

Test 2

Code: Select all

dim shared as byte DATA_STUFF( 27000 ) = { _
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14, ... etc
}

Since the files are too large to post here I had to upload them to my dropbox :
https://www.dropbox.com/s/u52cq9fzvnc8x ... 1.bas?dl=0
https://www.dropbox.com/s/qiwfpn5yjksvq ... 2.bas?dl=0

[adele]

Hi,
no idea about the reason, but: On my PC prog#2 crashes with x32 as well as with x64, both FB 1.05/Win
But: I found a "magic number", so others don´t need to try out: 26170 (last good one), 26171 (and above: crash)
And: it is NO matter of memory; tried in VM with 2 to 8 GB, and even explicit use of LONGINT was OK for 26170 .
Hope this helps a bit.

Adi

[fxm]

I suppose there is a size limitation on capacity to parse a line continuation, but fbc should provide an error message.

[cbruce]

Definitely line continuation parsing issue. I combined 30 of the lines... no error. Added 10 continued lines at the bottom, still no error.

If it works for you sero, just use longer lines.

[counting_pine]

I guess it's probably some kind of stack overflow in the compiler. Maybe a recursive function that doesn't need to be.
Would someone mind filing a bug report?

[sero]

Definitely line continuation parsing issue. I combined 30 of the lines... no error. Added 10 continued lines at the bottom, still no error.

Thanks for giving this some attention guys. I was originally guessing the problem was related to the volume of data and not the number of lines.

[srvaldez]

tip: instead of

Code: Select all

dim shared as byte DATA_STUFF( 27000 ) = { _
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14, ... etc
}


you can

Code: Select all

dim shared as byte DATA_STUFF( ... ) = { _
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14, ... etc
}


[lizard]

Great, srvaldez, learning more each day.

Code: Select all

dim shared as byte DATA_STUFF( ... ) = { _
0,1,2,3,4,5,6,7,8,9,10,11,12,13,14}

for i as integer = 0 to ubound(DATA_STUFF)
  print DATA_STUFF(i)
next i

sleep


[cbruce]

Ok... *NOT* A LINE CONTINUATION PARSING ERROR !

It's the number of static elements in an array assignment !

26170 static elements *MAX*... if using DIM( ... ) optional method.
26169 static elements *MAX*... if using DIM( nnnn ) hardcoded method.

I tried scenarios with 1 element per line - some multiple per line mixed with 1 per line - and finally this 30 lines of 1000 elements per line.

Note: Several of the test scenario results are included as comments in the code below.

Code: Select all

PRINT "TEST_10"
print "DIM( ... )"
print "Create 30,000 data elements for assigning to an array."
print "30 rows of 1,000 elements each."
print "==> ABEND during compile."

' Code to generate 30,000 data elements ...
'print
'print "Create 30,000 data elements for assigning to an array."
'print "30 rows of 1,000 elements each."
'print
'print "NOTE: Make sure to remove the last comma ... but *not* the continuation character!"
'print
'print "After printing to the console, copy and paste the"
'print "data elements to the array assignment."
'print
'for i as integer = 1 to 30
'    for k as integer = 1 to 1000
'        dim x as integer = 0
'        print str(x);",";
'        if k = 1000 then print " _"
'    next
'next
'print
'print
'
'
'
'PRINT "TEST_09"
'print "Instead of ( ... ) optional DIM argument, hardcoded ( 100000 ) argument"
'print "DIM( 100000 )"
'print "Started with one (1) element per line... (26170 elements)"
'PRINT "(+) 20 elements on first assignment line"
'print "(-) 20 single elements"
'print "==> ABEND during compile."
'print "BUT..."
'print "==> WORKS = ubound = 100000... If I go down to (26169 elements)"
'print "... maybe a hardcoded DIM argument uses some of the space available?"
'
'PRINT "TEST_08"
'print "DIM( ... )"
'print "Started with one (1) element per line... (26170 elements)"
'PRINT "(+) 20 elements on first assignment line"
'print "(-) 20 single elements"
'print "==> WORKS = ubound = 26169"
'
'PRINT "TEST_07"
'print "DIM( ... )"
'print "Started with one (1) element per line... (26170 elements)"
'PRINT "(+) 20 elements on first assignment line"
'print "(-) 10 single elements"
'print "==> ABEND during compile."
'
'PRINT "TEST_06"
'print "DIM( ... )"
'print "Started with one (1) element per line... (26170 elements)"
'PRINT "(+) 20 elements on first assignment line"
'print "==> ABEND during compile."
'
'PRINT "TEST_05"
'print "DIM( ... )"
'print "Started with one (1) element per line... (26170 elements)"
'print "==> WORKS = ubound = 26169"
'print "BUT...
'print "==> ABEND during compile... at (26171 elements)!"
'print " ===================================================="
'print "(This is what @adele noted in the message thread)"
'print " ===================================================="
'
'
'
dim shared as byte DATA_STUFF( ... ) = _
{ _

      ' PASTE THE 30,000 TEST ELEMENTS IN HERE... (from code above).

}
'
'
print
print
print
print "UBound() = "; ubound(DATA_STUFF)
print
print "@sero ...."
print "32/64 bit compiler issue"
print "https://www.freebasic.net/forum/viewtopic.php?f=2&t=26576"
PRINT "WORKS FOR ME IN 32 BIT"
PRINT "DOES NOT WORK FOR ME IN 64 BIT"

SLEEP

[dkl]

It sounds like: https://sourceforge.net/p/fbc/bugs/798/

[srvaldez]

hello cbruce
I have one suggestion, try increasing the stack

-t <value> Set .exe stack size in kbytes, default: 1024 (win32/dos)

on second thought that probably won't help as it seems to be a compiler's limitation.