FreeBASIC 1.10.1 Release Discussion

General discussion for topics related to the FreeBASIC project or its community.
Post Reply
coderJeff
Site Admin
Posts: 4326
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

FreeBASIC 1.10.1 Release Discussion

Post by coderJeff »

1.10.1 - Update 2023.12.25
Forum News Post: Version 1.10.1 Released

Start of 1.10.0 release discussion in this thread:
Jump to the post in this discussion on the 1.10.1 release


1.10.0 - Update 2023.05.14:
Forum News Post: Version 1.10.0 Released

Github: FreeBASIC 1.10.0 release on github
Sourceforge: Download files and readme.md

Start of 1.10.0 release discussion in this thread:
Jump to the post in this discussion on the 1.10.0 release
Last edited by coderJeff on Dec 25, 2023 5:56, edited 3 times in total.
Xusinboy Bekchanov
Posts: 791
Joined: Jul 26, 2018 18:28

Re: FreeBASIC 1.10.0 Development

Post by Xusinboy Bekchanov »

I can't compile version 1.10.0 on Windows:

Code: Select all

CC src/rtlib/obj/win32/time_weekdayname.o
CC src/rtlib/obj/win32/utf_convfrom_char.o
CC src/rtlib/obj/win32/utf_convto_char.o
CC src/rtlib/obj/win32/utf_convto_wchar.o
CC src/rtlib/obj/win32/utf_core.o
CC src/rtlib/obj/win32/vfs_open.o
CPPAS src/rtlib/obj/win32/cpudetect.o
src/rtlib/x86/cpudetect.s: Assembler messages:
src/rtlib/x86/cpudetect.s:29: Error: operand type mismatch for `push'
src/rtlib/x86/cpudetect.s:31: Error: operand type mismatch for `push'
src/rtlib/x86/cpudetect.s:32: Error: operand type mismatch for `push'
src/rtlib/x86/cpudetect.s:33: Error: operand type mismatch for `push'
src/rtlib/x86/cpudetect.s:36: Error: invalid instruction suffix for `pushf'
src/rtlib/x86/cpudetect.s:37: Error: operand type mismatch for `pop'
src/rtlib/x86/cpudetect.s:40: Error: operand type mismatch for `push'
src/rtlib/x86/cpudetect.s:41: Error: invalid instruction suffix for `popf'
src/rtlib/x86/cpudetect.s:42: Error: invalid instruction suffix for `pushf'
src/rtlib/x86/cpudetect.s:43: Error: operand type mismatch for `pop'
src/rtlib/x86/cpudetect.s:51: Error: invalid instruction suffix for `pushf'
src/rtlib/x86/cpudetect.s:52: Error: operand type mismatch for `pop'
src/rtlib/x86/cpudetect.s:55: Error: operand type mismatch for `push'
src/rtlib/x86/cpudetect.s:56: Error: invalid instruction suffix for `popf'
src/rtlib/x86/cpudetect.s:57: Error: invalid instruction suffix for `pushf'
src/rtlib/x86/cpudetect.s:58: Error: operand type mismatch for `pop'
src/rtlib/x86/cpudetect.s:66: Error: operand type mismatch for `push'
src/rtlib/x86/cpudetect.s:83: Error: operand type mismatch for `pop'
src/rtlib/x86/cpudetect.s:84: Error: operand type mismatch for `pop'
src/rtlib/x86/cpudetect.s:85: Error: operand type mismatch for `pop'
src/rtlib/x86/cpudetect.s:86: Error: operand type mismatch for `pop'
make.exe": *** [src/rtlib/obj/win32/cpudetect.o] Error 1
---


On Linux, the new version (1.10.0) compiles. But this code:

Code: Select all

Type MyType
	c As String
End Type

#define MyTypeFromPtr(__Ptr__) *Cast(MyType Ptr, __Ptr__)

Dim As Any Ptr pMyType = New MyType
MyTypeFromPtr(pMyType).c = "dsdsd"
Gives compiler errors:
Untitled.bas(8) error 265: Symbol not a CLASS, ENUM, TYPE or UNION typem before '.'
fxm
Moderator
Posts: 12132
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.10.0 Development

Post by fxm »

Xusinboy Bekchanov wrote: Dec 18, 2022 5:31 new version (1.10.0)
this code:

Code: Select all

Type MyType
	c As String
End Type

#define MyTypeFromPtr(__Ptr__) *Cast(MyType Ptr, __Ptr__)

Dim As Any Ptr pMyType = New MyType
MyTypeFromPtr(pMyType).c = "dsdsd"

Gives compiler errors:
Untitled.bas(8) error 265: Symbol not a CLASS, ENUM, TYPE or UNION typem before '.'

Due to the change for version 1.10.0:
- sf.net #811: *(ptr).field should give an error

The operator precedence must be taken into account:
The '.' operator takes precedence on the '*' operator.

See my previous alert message:
fxm wrote: Dec 07, 2022 10:37 Attention users:

The old '#811 *(ptr).field should give an error' bug is now fixed for fbc version 1.10.0 (and later).
I noticed that some used this wrong expression '*(ptr).field' in their code.
They will need to replace it with the valid expression: '(*ptr).field'

Same problem for a pointeur to procedure-pointer 'Ptr_to_ProcPtr'.
Use:
'(*Ptr_to_ProcPtr)()' instead of '*Ptr_to_ProcPtr()'
'(*Ptr_to_ProcPtr)(...)' instead of '*(Ptr_to_ProcPtr)(...)'

(this post because who reads the 'changelog.txt' file besides me ?)

Therefore the proper syntax for your #define is (with outer parentheses):
#define MyTypeFromPtr(__Ptr__) (*Cast(MyType Ptr, __Ptr__))
instead of:
#define MyTypeFromPtr(__Ptr__) *Cast(MyType Ptr, __Ptr__)
pidd
Posts: 31
Joined: Nov 11, 2022 16:27

Re: FreeBASIC 1.10.0 Development

Post by pidd »

Weird, I haven't seen any make errors on linux-aarch64, I check for updates daily, currently Version 1.10.0 (2022-12-09)
fxm
Moderator
Posts: 12132
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.10.0 Development

Post by fxm »

Where do you find the daily build for Linux ?
pidd
Posts: 31
Joined: Nov 11, 2022 16:27

Re: FreeBASIC 1.10.0 Development

Post by pidd »

I pull from master branch on git https://github.com/freebasic/fbc.git or are you asking OP, soz.
fxm
Moderator
Posts: 12132
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.10.0 Development

Post by fxm »

So you are compiling the development version of FreeBASIC?
coderJeff
Site Admin
Posts: 4326
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: FreeBASIC 1.10.0 Development

Post by coderJeff »

Xusinboy Bekchanov wrote: Dec 18, 2022 5:19 I can't compile version 1.10.0 on Windows:
What tool chain are you using? There are no recent changes to 'makefile' or cpudetect.s so if seems unusual that you would suddenly get these errors if you have been regularly building from sources.
Xusinboy Bekchanov
Posts: 791
Joined: Jul 26, 2018 18:28

Re: FreeBASIC 1.10.0 Development

Post by Xusinboy Bekchanov »

coderJeff wrote: Dec 18, 2022 17:03
Xusinboy Bekchanov wrote: Dec 18, 2022 5:19 I can't compile version 1.10.0 on Windows:
What tool chain are you using?
I use mingw, I don't compile regularly.
srvaldez
Posts: 3379
Joined: Sep 25, 2005 21:54

Re: FreeBASIC 1.10.0 Development

Post by srvaldez »

hello Xusinboy Bekchanov :)
the only thing that I can think of that causes the assembler errors is that you are using a very old version of mingw, give the gcc version and assembler version, for example gcc --version and as --version
Xusinboy Bekchanov
Posts: 791
Joined: Jul 26, 2018 18:28

Re: FreeBASIC 1.10.0 Development

Post by Xusinboy Bekchanov »

srvaldez wrote: Dec 19, 2022 12:33 hello Xusinboy Bekchanov :)
the only thing that I can think of that causes the assembler errors is that you are using a very old version of mingw, give the gcc version and assembler version, for example gcc --version and as --version
Hello.
The results are:
D:\GitHub\fbc-master>gcc --version
gcc (x86_64-win32-sjlj-rev0, Built by MinGW-W64 project) 5.2.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


D:\GitHub\fbc-master>as --version
GNU assembler (GNU Binutils) 2.25
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-w64-mingw32'.
I'll try to update them.
Xusinboy Bekchanov
Posts: 791
Joined: Jul 26, 2018 18:28

Re: FreeBASIC 1.10.0 Development

Post by Xusinboy Bekchanov »

fxm wrote: Dec 18, 2022 6:05 Due to the change for version 1.10.0:
- sf.net #811: *(ptr).field should give an error

The operator precedence must be taken into account:
The '.' operator takes precedence on the '*' operator.

See my previous alert message:
fxm wrote: Dec 07, 2022 10:37 Attention users:

The old '#811 *(ptr).field should give an error' bug is now fixed for fbc version 1.10.0 (and later).
I noticed that some used this wrong expression '*(ptr).field' in their code.
They will need to replace it with the valid expression: '(*ptr).field'

Same problem for a pointeur to procedure-pointer 'Ptr_to_ProcPtr'.
Use:
'(*Ptr_to_ProcPtr)()' instead of '*Ptr_to_ProcPtr()'
'(*Ptr_to_ProcPtr)(...)' instead of '*(Ptr_to_ProcPtr)(...)'

(this post because who reads the 'changelog.txt' file besides me ?)

Therefore the proper syntax for your #define is (with outer parentheses):
#define MyTypeFromPtr(__Ptr__) (*Cast(MyType Ptr, __Ptr__))
instead of:
#define MyTypeFromPtr(__Ptr__) *Cast(MyType Ptr, __Ptr__)
Thank you.
fxm
Moderator
Posts: 12132
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.10.0 Development

Post by fxm »

@Jeff,

1) REGRESSION for FBC rev 1.10.0 between mid-July and end-November 2022 ?
The simplest conversion-construction from a derived instance no longer works.

(I have not kept enough previous builds to be more precise on the date of the regression)

Code: Select all

Type Parent
    Dim As Integer I
End Type

Type Child Extends Parent
End Type

Dim As Child c

Dim As Parent p = c             '' error 24: Invalid data types in 'Dim As Parent p = c'

Sleep
Normally an implicit cast (from Child to Parent) should be applied.
However this code works as soon as:
- a copy-constructor is defined (explicitly or implicitly) in Parent,
- or a matching conversion-constructor in Parent,
- or an explicit cast operator to Parent in Child.

2) Otherwise, all other conversion expressions (from Child instance to Parent instance) work !

Code: Select all

Type Parent
    Dim As Integer I
End Type

Type Child Extends Parent
End Type

Dim As Child c
Dim As Parent p1

p1 = c

Sub s1(Byval p As Parent)
End Sub
s1(c)

Function f1() As Parent
    Dim As Child c
    Function = c
End function
f1()

Function f2() As Parent
    Dim As Child c
    Return c
End function
f2()

'Dim As Parent p = c  '' error 24: Invalid data types in 'Dim As Parent p = c'

Sleep

3) Of all the other conversion cases tested in the entire ''Conversion/Inheritance relating to UDTs via constructors and operators' thread, I found no other regressions.
fxm
Moderator
Posts: 12132
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.10.0 Development

Post by fxm »

fxm wrote: Dec 21, 2022 13:17 @Jeff,

1) REGRESSION for FBC rev 1.10.0 between mid-July and end-November 2022 ?
The simplest conversion-construction from a derived instance no longer works.

Maybe a side effect of this fix (fbc: typeini):
sf.net #968: fbc: major changes on how initializers
- fixes/changes how fbc handles pairing of a UDT's (internal) structure and the initializer list given by the user
- new: track the overall initializer size in bytes
- don't allow implicit casting to base types
- pass back the initializer to a parent field for full initialization instead of truncated initialization
- determine next field to initialize based on the overall bytes initialized instead of only the 'next field'
Note: This variant of the above bug 'Dim As Parent p = Type<Child>(1)' should also compile.
Xusinboy Bekchanov
Posts: 791
Joined: Jul 26, 2018 18:28

Re: FreeBASIC 1.10.0 Development

Post by Xusinboy Bekchanov »

srvaldez wrote: Dec 19, 2022 12:33 hello Xusinboy Bekchanov :)
the only thing that I can think of that causes the assembler errors is that you are using a very old version of mingw, give the gcc version and assembler version, for example gcc --version and as --version
The solution to this problem, it turns out, is here:
https://stackoverflow.com/questions/526 ... h-for-push

Should have added -m32 before cpudetect.s

Now it compiles correctly.
Post Reply