Found another compiler bug: "operand type mismatch for `call'"

For other topics related to the FreeBASIC project or its community.
Manpcnin
Posts: 21
Joined: Feb 25, 2007 1:43
Location: N.Z.

Found another compiler bug: "operand type mismatch for `call'"

Postby Manpcnin » Jul 31, 2020 3:43

Certain function and subroutine names cause an unexpected backend assembler error:

Command executed:
"C:\Coding\FreeBASIC-1.07.1\fbc.exe" "C:\Coding\FreeBASIC-1.07.1\FBIDETEMP.bas"

Compiler output:
C:\Coding\FreeBASIC-1.07.1\FBIDETEMP.asm: Assembler messages:
C:\Coding\FreeBASIC-1.07.1\FBIDETEMP.asm:31: Error: operand type mismatch for `call'


To replicate:

Code: Select all

sub SS()
end sub
SS()


Number of parameters or return type seem to have no affect. Just the name: "SS"

Only tested on FBC 1.07.1 64bit so far.
fxm
Posts: 9722
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Found another compiler bug: "operand type mismatch for `call'"

Postby fxm » Jul 31, 2020 5:37

The use of registry names as FreeBASIC symbols is still surprising in 64-bit.
@admin, can we do something about this?
No problem in 32-bit, even with gcc?
D.J.Peters
Posts: 8040
Joined: May 28, 2005 3:28
Contact:

Re: Found another compiler bug: "operand type mismatch for `call'"

Postby D.J.Peters » Jul 31, 2020 9:01

satire: wikipedia: SS isn't allowed in Germany !
SARG
Posts: 1100
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Found another compiler bug: "operand type mismatch for `call'"

Postby SARG » Jul 31, 2020 15:58

fxm wrote:No problem in 32-bit, even with gcc?
No problem as either '@n' or an underscore is added.
But on 64bit nothing is done.

@Manpcnin
You can use the new 64bit emitter : gas64 see viewtopic.php?f=8&t=27478
A '$' is added at the end of each name (global variable and procedure) so no problem. Local variables have already a suffixe added for getting an unique name.

Last version for Windows. http://users.freebasic-portal.de/sarg/f ... DS_exe.zip Use the exe as the regular one.
MrSwiss
Posts: 3542
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Found another compiler bug: "operand type mismatch for `call'"

Postby MrSwiss » Jul 31, 2020 16:05

The simple solution is, however:

do NEVER use any, in inline ASM used specifiers, as 'names' in FB-code and,
you'll never fall into that 'open' trap (as soon as inline ASM is used, at the latest).
SARG
Posts: 1100
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Found another compiler bug: "operand type mismatch for `call'"

Postby SARG » Jul 31, 2020 16:22

@MrSwiss,

Do you know all the asm words ? Marcov gave the number, about 1500... Many seem 'innocent'

And I don't understand, the issue is not only with inline asm.
dim as integer rax or sub word() are a problem.
MrSwiss
Posts: 3542
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Found another compiler bug: "operand type mismatch for `call'"

Postby MrSwiss » Jul 31, 2020 16:41

SARG wrote:dim as integer 'rax' or sub 'word'() are a problem.
There you have it, as I've stated: using it as 'name', whether a variable or a const or a procedure 'name'.
SARG
Posts: 1100
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Found another compiler bug: "operand type mismatch for `call'"

Postby SARG » Jul 31, 2020 17:11

@MrSwiss
Why prevent a coder to use the word 'aaa' as name ? And the list could be long.
AAA = ASCII Adjust After Addition.

IMHO it's better to let the use of these words as they are not related to freebasic.

And as we can see in the OP's post the error is not clear.... it would be necessary to test all the words, it's simplier/faster to allow them.


PS I dont' want to start a new war just my humble opinion and I have already let the possibility in gas64 :-)
counting_pine
Site Admin
Posts: 6211
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Found another compiler bug: "operand type mismatch for `call'"

Postby counting_pine » Jul 31, 2020 20:21

I'm not an expert, but it seems to be a pretty fundamental problem in the masm intel syntax.
It's easily shown with a simple program in GCC:

Code: Select all

// compile with gcc -masm intel
int ss(){
}

/tmp/ccOC4unv.s: Assembler messages:
/tmp/ccOC4unv.s: Error: .size expression for ss does not evaluate to a constant


MASM seems pretty unashamed of this. See also http://www.c-jump.com/CIS77/ASM/Instruc ... m_language:
The assembler generates an error if you use a reserved word as a variable, code label, or other identifier.

Maybe fbc can be persuaded to let GCC use a different assembly format. I don't know..
SARG
Posts: 1100
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Found another compiler bug: "operand type mismatch for `call'"

Postby SARG » Jul 31, 2020 20:36

The assembler generates an error if you use a reserved word as a variable, code label, or other identifier.

Sure but it concerns asm code handled in the assembler.

An equivalent in freebasic : dim as integer print --> error 4: Duplicated definition, found 'print' in 'dim as integer print'

However in sub qword(), qword is not a word of the language so it should be allowed.
Manpcnin
Posts: 21
Joined: Feb 25, 2007 1:43
Location: N.Z.

Re: Found another compiler bug: "operand type mismatch for `call'"

Postby Manpcnin » Aug 01, 2020 2:03

I guessed by the error message that it was an assembly keyword. What I considered a bug was that name mangling or whatever the FBC uses to tokenize Variables & Functions, passes a reserved ASM name through to the backend unchanged.
counting_pine
Site Admin
Posts: 6211
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Found another compiler bug: "operand type mismatch for `call'"

Postby counting_pine » Aug 01, 2020 8:20

Well, the immediate backend is now generally GCC, which produces the bad asm..

It might be worth saying, a relatively unobtrusive workaround that allows you to keep the SS name is to #define SS as something else.
If you have more of them, you can stash them away in an #include somewhere. Just bear in mind that code in another module will also need to refer to it by the same name.

It might also work if you Alias the function name to something else. Not sure what effect that has on the emitted C/asm code.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 4 guests