Where can I get a Recent-Git-Build of FreeBASIC?

SARG · Postby **SARG** » Apr 16, 2012 12:33

@fxm
Compile date : 11/04
Effectively I missed (or forgot) it. Changing inc by include it works.
Thanks.

MOD · Postby **MOD** » Apr 16, 2012 16:30

New builds uploaded.

fxm · Postby **fxm** » Apr 16, 2012 19:19

fxm wrote:I isolated another little more complex compilation bug :
Suppressing the 'If ... End If', the compiler error disappears!.
Suppressing the 'Local', the compiler error disappears (it would be the opposite)!!!
Code: Select all
Sub test If -1 Then On Local Error Goto bug label: End If Exit Sub bug: Goto label End Sub

An improved program to better enlighten the different behaviors:

- The same error as above.

Code: Select all

Sub test (Byval er As Integer)
  If -1 Then
    On Local Error Goto bug
'    On Error Goto bug
    If er Then
      Error er
    End if
    Print "no error"
label: 
  End If
  Exit Sub
bug:
  Print "error"; er
  Goto label
End Sub

test(0)
test(1)
Sleep

Command executed:

Compiler output:

Results:

System:

- Suppressing the 'If ... End If', the compiler error disappears and the program works fine!

Code: Select all

Sub test (Byval er As Integer)
'  If -1 Then
    On Local Error Goto bug
'    On Error Goto bug
    If er Then
      Error er
    End if
    Print "no error"
label: 
'  End If
  Exit Sub
bug:
  Print "error"; er
  Goto label
End Sub

test(0)
test(1)
Sleep

Command executed:

Results:

System:

Code: Select all

no error
error 1

- Suppressing the 'Local', the compiler error disappears (it would be the opposite), and the program works fine!!!

Code: Select all

Sub test (Byval er As Integer)
  If -1 Then
'    On Local Error Goto bug
    On Error Goto bug
    If er Then
      Error er
    End if
    Print "no error"
label: 
  End If
  Exit Sub
bug:
  Print "error"; er
  Goto label
End Sub

test(0)
test(1)
Sleep

Command executed:

Results:

System:

Code: Select all

no error
error 1

SARG · Postby **SARG** » Apr 17, 2012 7:42

@fxm
I try to use the gcc option.
With the file in this directory "C:\temp\dev\freebasic\bin\libexec\gcc\mingw32\3.4.5" and the fbc exe in FreeBASIC-win-SVN-20120203.zip no problem. But with the version dated 11/04 I got :

assembling failed: 'c:\TEMP\dev\freebasic\bin\gcc.exe' terminated with exit code 1
gcc.exe: installation problem, cannot exec `cc1': No such file or directory

Where must be the cc1.exe ? I have tried different possibilities without success.

Thanks in advance.

fxm · Postby **fxm** » Apr 17, 2012 8:27

SARG wrote:@fxm
I try to use the gcc option.
With the file in this directory "C:\temp\dev\freebasic\bin\libexec\gcc\mingw32\3.4.5" and the fbc exe in FreeBASIC-win-SVN-20120203.zip no problem. But with the version dated 11/04 I got :

assembling failed: 'c:\TEMP\dev\freebasic\bin\gcc.exe' terminated with exit code 1
gcc.exe: installation problem, cannot exec `cc1': No such file or directory

Where must be the cc1.exe ? I have tried different possibilities without success.

Thanks in advance.

My configuration which works (because there is no more the directory 'win32' in theses MOD's builds):

'fbc0.24_windows20120416+gcc\bin': ld.exe, GoRC.exe, dlltool.exe, as.exe, ar.exe, gcc.exe
'fbc0.24_windows20120416+gcc\libexec\gcc\mingw32\3.4.5': as.exe, cc1.exe

The directory 'libexec\gcc\mingw32\3.4.5' is now directly under the directory 'fbc0.24_windows20120416+gcc' which contains 'fbc.exe', at the same level than the directory 'bin' (because the directory 'win32' no more exists).

Remark: I have always been obliged (even with the official revisions or SVN builds) to duplicate the file 'as.exe' to avoid the following error message:
gcc.exe: installation problem, cannot exec `as': No such file or directory

SARG · Postby **SARG** » Apr 17, 2012 10:55

fxm wrote:The directory 'libexec\gcc\mingw32\3.4.5' is now directly under the directory 'fbc0.24_windows20120416+gcc' which contains 'fbc.exe', at the same level than the directory 'bin' (because the directory 'win32' no more exists).

That's the solution, thanks.

Now compiling these lines, I got warnings. Not really a problem just to signal it.

Code: Select all

print "teszt"
sleep

Warning: .drectve `-aligncomm:"___fb_ctx",5' unrecognized
Warning: .drectve `-aligncomm:"___fb_con",5' unrecognized
Warning: .drectve `-aligncomm:"___DTOR_LIST__",2 ' unrecognized
Warning: .drectve `-aligncomm:"___CTOR_LIST__",2' unrecognized

fxm · Postby **fxm** » Apr 17, 2012 11:05

SARG wrote:Now compiling these lines, I got warnings. Not really a problem just to signal it.
Code: Select all
print "teszt" sleep

Warning: .drectve `-aligncomm:"___fb_ctx",5' unrecognized
Warning: .drectve `-aligncomm:"___fb_con",5' unrecognized
Warning: .drectve `-aligncomm:"___DTOR_LIST__",2 ' unrecognized
Warning: .drectve `-aligncomm:"___CTOR_LIST__",2' unrecognized

No warning for me!

Command executed:
"d:\Documents and Settings\t0003830\Mes documents\fbc0.24_windows20120416+gcc\fbc.exe" "d:\Documents and Settings\t0003830\Mes documents\FBIde0.4.6r4\FBIDETEMP.bas" -gen gcc -exx -w pedantic

Results:
Compilation successful
Generated executable: d:\Documents and Settings\t0003830\Mes documents\FBIde0.4.6r4\FBIDETEMP.exe

System:
FBIde: 0.4.6
fbc: FreeBASIC Compiler - Version 0.24.0 (04-16-2012) for win32
OS: Windows XP (build 2600, Service Pack 3)

Remark 1:
My directory 'fbc0.24_windows20120416+gcc' corresponds to the directory 'fbc0.24_windows20120416' from 'FreeBASIC-win-SVN-20120203.zip' (http://www.freebasic-portal.de/download ... uilds.html) plus the files for gcc as described above:
'fbc0.24_windows20120416+gcc\bin': ld.exe, GoRC.exe, dlltool.exe, as.exe, ar.exe, gcc.exe
'fbc0.24_windows20120416+gcc\libexec\gcc\mingw32\3.4.5': as.exe, cc1.exe

Remark 2:
Theses warnings are similar to problems one year ago, at the beginning of the new fbc branch ('inheritance') on sourceforge (fbc SVN):
viewtopic.php?p=156526#p156526
viewtopic.php?p=156540#p156540
viewtopic.php?p=156572#p156572
viewtopic.php?p=156576#p156576
(one year ago, the disappearance of these warnings had not been really explained)

SARG · Postby **SARG** » Apr 17, 2012 13:29

@fxm
Une "mémoire d'éléphant" (a memory of elephant) ;-)

fxm wrote:Theses warnings are similar to problems one year ago, at the beginning of the new fbc branch ('inheritance') on sourceforge (fbc SVN):
(one year ago, the disappearance of these warnings had not been really explained)

I copied all from 'FreeBASIC-win-SVN-20120203.zip' then from 'fbc0.24_windows20120416' and no more warnings.

fxm · Postby **fxm** » Apr 17, 2012 19:18

SARG wrote:I copied all from 'FreeBASIC-win-SVN-20120203.zip' then from 'fbc0.24_windows20120416' and no more warnings.

Oui, mais c'est un peu lourd comme un éléphant (Yes, but it's a little heavy as an elephant).
The directories 'bin\win32', 'lib\win32', 'inc' become useless with the new 'fbc.exe' ('bin\win32' and 'lib\win32' ignored, and the third replaced by 'include').

AGS · Postby **AGS** » Apr 18, 2012 6:55

I posted a bug report in 2010 about a program not working when using -gen gcc
http://sourceforge.net/tracker/index.ph ... tid=693196

ID: 3031710

And the bug is fixed when using the newest version of fbc. That is, when using -g -gen gcc. When not using -g I get compiler errors. I've looked at the C code produced but found nothing interesting (nothing that could explain why compilation fails when not using -g).

I tried with an older fbc version and found the same thing: with -g -gen gcc the code compiles, without -g it doesn't compile.
So it seems like mingw is doing something "different" when using -g (using mingw version 3.4.5). Seems like there is little the fbc devs can do to fix the bug as it's mingw that seems to be causing the problems. Pity I have to use -g as using -g results in the creation of rather sizeable executables.

I noticed the option -mtune=athlon is in the build options when using -gen gcc (-mtune = athlon). My PC does not come with an athlon processor (Intel I7). The value used for the -mtune option is set when building the freebasic compiler (it's set during evaluation of the make file where the cpu type gets set using uname -m). uname -m on my pc yields i686 (not athlon). I don't think it will cause problems when compiling programs though.

fxm · Postby **fxm** » Apr 18, 2012 7:08

AGS wrote:I posted a bug report in 2010 about a program not working when using -gen gcc
http://sourceforge.net/tracker/index.ph ... tid=693196

ID: 3031710

And the bug is fixed when using the newest version of fbc. That is, when using -g -gen gcc. When not using -g I get compiler errors. I've looked at the C code produced but found nothing interesting (nothing that could explain why compilation fails when not using -g).

Have you tried to isolate the bug in a short code?

SARG · Postby **SARG** » Apr 18, 2012 9:16

@AGS
Fbdebugger is compiled without problem (except warnings) with/without the -g option.
By the way, it partially works with the debuggees compiled with the -gen gcc option. But there are still many issues to be resolved. :-(

About your issse, could you test : compile with the -R option (obviously without -g), add a dummy debug line to the c file.
#line 0 "C:\\TEMP\\dev\\testgcc2.bas" just to have at least one data in the debug area
And continue the compilation with the -g option in the gcc.exe command.

AGS · Postby **AGS** » Apr 19, 2012 6:24

fxm wrote:
AGS wrote:I posted a bug report in 2010 about a program not working when using -gen gcc
http://sourceforge.net/tracker/index.ph ... tid=693196

ID: 3031710

And the bug is fixed when using the newest version of fbc. That is, when using -g -gen gcc. When not using -g I get compiler errors. I've looked at the C code produced but found nothing interesting (nothing that could explain why compilation fails when not using -g).

Have you tried to isolate the bug in a short code?

Yes, I have. Here is a type definition and an alias. The alias is needed as action is defined later on in the source code.

Code: Select all

type __action__ as action
type state
declare sub addaction(byval act as __action__ ptr)
end type

Now the definition of addaction.

Code: Select all

sub state.addaction(byVal act as action ptr)
''code
end sub

As you can see the parameter list went from __action__ ptr to action ptr. Reason being that somewhere between
the declaration and the definition the type action was introduced. So the alias is no longer needed and the routine can use the real thing. As __action__ is an alias for action there should not be a problem as an action ptr and a __action__ ptr are one and the same thing (or so you'd think).

In the resulting C code this is what I got
First the declaration (mangled as it's inside a namespace and the sub is part of a type)

Code: Select all

void  __stdcall _ZN4COCO5STATE9ADDACTIONEPNS_6ACTIONE( COCO$STATE *, void* );

As you can see the __action__ ptr has turned into a void ptr.

And this is the start of the definition of addaction

Code: Select all

void __stdcall  _ZN4COCO5STATE9ADDACTIONEPNS_6ACTIONE( COCO$STATE *THIS$, COCO$ACTION* ACT$ )

And there is the action ptr (COCO$ACTION* ACT$). So the parameter went from void* to COCO$ACTION*. The freebasic front end does not complain about the basic source code and emits C code. Then gcc tries to compile the C code and chokes on void* versus COCO$ACTION * stating that "void* and COCO$ACTION* are not one and the same thing.". As __state__ is an alias for state there should not be a problem: a __state__ and a state are one and the same thing.
Why using -g makes the above problem disappear is beyond me. Looking at the C code I think the C compiler is right when
complaining about the different types used for the second parameter of addaction.

At the point of declaration of addaction the type of action is not know. There is not even an alias.
Hence the use of void*. I think the problem can be solved using a slightly different kind of declaration scheme.

Code: Select all

#include <stdlib.h>

typedef struct action __action__;

int a(__action__ *b);

struct action{
  int a;
};

int main()
{
  struct action *b;
  b = calloc(1,sizeof(struct action));
  b->a = 88;
  a(b);
  free(b);
  return 1;
};

int a(struct action* b)
{
  printf("%d",b->a);
  return 1;
};

The above works when compiled using tcc. The scheme used (introduce alias for action then use alias in declaration)
differs a bit from what the gcc back end tends to use. The scheme used by the gcc back end does not always work.
The gcc back end could have produced the typedef struct action __action__ and then use the alias __action__
in functions needing a pointer to an action. So regardless of the weird behaviour of gcc I think the
gcc back end could produce introduce aliases earlier then it does right now.

I noticed the gcc back end tends to emit void* as well when translating a dynamic array of simple type
(say something like redim array(0 to 8) as short). I really ought to take a much closer look at the gcc
back end.

fxm · Postby **fxm** » Apr 19, 2012 7:23

I have no problem with this simple example:

Code: Select all

type __action__ as action

type state
  declare sub addaction(byval act as __action__ ptr)
  not_used as byte
end type

type action
  dim array(10) as integer
end type

sub state.addaction(byVal act as action ptr)
''code
end sub

Command executed:

Results:

System:

Code: Select all

// Compilation of d:\Documents and Settings\t0003830\Mes documents\FBIde0.4.6r4\FBIDETEMP.bas started at 09:19:31 on 04-19-2012
typedef char byte;
typedef unsigned char ubyte;
typedef unsigned short ushort;
typedef int integer;
typedef unsigned int uinteger;
typedef unsigned long ulong;
typedef long long longint;
typedef unsigned long long ulongint;
typedef float single;
typedef struct _string { char *data; int len; int size; } string;
typedef char fixstr;
typedef ushort wchar;
typedef struct _STATE {
   byte NOT_USED;
} STATE;
typedef struct _ACTION {
   integer ARRAY[11];
} ACTION;
void __attribute__((stdcall)) _ZN5STATE9ADDACTIONEP6ACTION( STATE*, ACTION* );
static void fb_ctor__FBIDETEMP( void ) __attribute__ ((constructor)) ;
typedef struct _$fb_RTTI $fb_RTTI$type;
typedef struct _$fb_RTTI {
   void* STDLIBVT;
   char* ID;
   $fb_RTTI$type* PRTTIBASE;
} $fb_RTTI;
extern $fb_RTTI$type __fb_ZTS6Object;

void __attribute__((stdcall)) _ZN5STATE9ADDACTIONEP6ACTION( STATE* THIS$, ACTION* ACT$ )
{
   label$2:;
   label$3:;
}
// Total compilation time: 0.0001762793874671154 seconds.

Sannaj · Postby **Sannaj** » Apr 19, 2012 20:19

Just a short thing I've just realised:

Why is "byte" defined as "char" in the C code´?

I think

Code: Select all

typedef signed char byte;

might be more matching since plain char not allays signed and not the "true" 8 bit Integer type.
For Strings you could still use fixstring defined below.

Where can I get a Recent-Git-Build of FreeBASIC?

Re: Where get a Recent-Git-Build of FreeBASIC?

Re: Where get a Recent-Git-Build of FreeBASIC?

Re: Where get a Recent-Git-Build of FreeBASIC?

Re: Where get a Recent-Git-Build of FreeBASIC?

Re: Where get a Recent-Git-Build of FreeBASIC?

Re: Where get a Recent-Git-Build of FreeBASIC?

Re: Where get a Recent-Git-Build of FreeBASIC?

Re: Where get a Recent-Git-Build of FreeBASIC?

Re: Where get a Recent-Git-Build of FreeBASIC?

Re:

Re: Where get a Recent-Git-Build of FreeBASIC?

Re: Where get a Recent-Git-Build of FreeBASIC?

Re: Where get a Recent-Git-Build of FreeBASIC?

Who is online