error w/gen gcc - solved

[speedfixer]

I have a large set of my own libraries. The functions are split up and all are compiled to static object files for later linking.
I have a system that handles all the includes. All has worked well. I have several hundred functions in 20+ library sets. This way, only what is used is linked; all executables are much smaller. With all these functions pre-compiled (some are not tiny like these two) - a large set of executables will still compile very fast.

This is Linux only. I had stepped away for more than a year from working with these, but I have paid attention to what is going on here. Not that many changes.
Now: new OS load (Debian) - updated gcc, FB, etc.

gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516

FreeBASIC Compiler - Version 1.06.0 (02-17-2019), built for linux-x86_64 (64bit)
Copyright (C) 2004-2019 The FreeBASIC development team.

The problem:

Code: Select all

declare sub rk_possave
declare sub rk_posrestore

sub rk_spinnerdone
' clear rk_spinner

rk_possave

locate 1,2,0
print " ";

rk_posrestore
end sub                                                      ' rk_spinnerdone

sub rk_spinner
' action flag - first line visual action cue

static as integer spinner_flag
static as double spinner_tpause

if spinner_tpause = 0 then spinner_tpause = timer
if timer - spinner_tpause < 0.18 then               ' period to wait before twitch
    exit sub
else
    spinner_tpause = timer
end if

dim as string pstr(1 to 4)

pstr(1) = chr(92)
pstr(4) = chr(45)
pstr(3) = chr(47)
pstr(2) = chr(124)

rk_possave
locate 1,2,0                            ' tiaw is at 1,1 - USUALLY only one char

spinner_flag += 1
if spinner_flag > 4 then spinner_flag = 1

print pstr(spinner_flag);

rk_posrestore
end sub                                                          ' rk_spinner

rk_possave and rk_posrestore simply records the position of the cursor before the call, then restores the cursor position on the restore. Not an issue.

command line:

fbc -gen gcc -O 2 -lib -exx rk_spinner.bas

returns:

rk_spinner.c: In function ‘RK_SPINNER’:
rk_spinner.c:101:26: warning: array subscript is below array bounds [-Warray-bounds]
*(FBSTRING**)&tmp$7$1 = (FBSTRING*)((uint8*)PSTR$1 + -24ll);

My results:
with, without -exx ONLY -- no problem

(any below, with or without -exx is the same result)

with -gen gcc ONLY -- no problem
with -gen gcc -O 0 or 1 -- no problem
with -gen gcc -O 2 or 3 -- above error message

Anyone have a hint or suggestion?

david

I have not gone through all the other libs and functions to see if any others have a similar problem. I have gone through about 60 or so and they were not a problem. I do expect to see more though.

[speedfixer]

That is really old code. Just rewrote cleaner, faster, smaller.

BUT ... the compile question still remains:

Why does -gen gcc -O 2 throw that array out of bounds warning (usually a segfault when run) but -O 1 does not?

This is a cleaner example of the fail code:

Code: Select all

declare sub spinner

while inkey <> "": wend

cls

print
print " start "
print

do
    sleep 10, 1
    spinner
loop while inkey = ""

print
print " done "
print

sub spinner
' action flag - first line visual action cue

static as integer spinner_flag
static as double spinner_tpause

dim as string pstr(1 to 4)

if spinner_tpause = 0 then spinner_tpause = timer
if timer - spinner_tpause < 0.18 then               ' period to wait before twitch
    exit sub
else
    spinner_tpause = timer
end if

pstr(1) = chr(92)
pstr(4) = chr(45)
pstr(3) = chr(47)
pstr(2) = chr(124)

locate 1,2,0

spinner_flag += 1
if spinner_flag > 4 then spinner_flag = 1

print pstr(spinner_flag);

end sub

Perhaps the FB translate of the string array and access to 'c' ?

[dodicat]

I only have 32 bit fbc in Red Hat Linux.(renamed Scientific Linux)
but
fbc -gen gcc -O 2 -lib -exx rk_spinner.bas
gives no warnings/errors and produces the library file.

[speedfixer]

What version of gcc?

[dodicat]

gcc version 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC)

[speedfixer]

Just remembered I have a couple of rPI and 10 other systems to test with.

Seems to work on them OK, some with same build of gcc.
Just something on this one system, I guess.
False alarm.

[ tears coming down ... can't trust this one, I guess ... another hour+ to flush and reload ...]