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

General discussion for topics related to the FreeBASIC project or its community.
Post Reply
Manpcnin
Posts: 46
Joined: Feb 25, 2007 1:43
Location: N.Z.

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

Post by Manpcnin »

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
Moderator
Posts: 12082
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

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

Post by fxm »

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: 8586
Joined: May 28, 2005 3:28
Contact:

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

Post by D.J.Peters »

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

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

Post by SARG »

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 https://freebasic.net/forum/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: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

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

Post by MrSwiss »

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: 1756
Joined: May 27, 2005 7:15
Location: FRANCE

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

Post by SARG »

@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: 3910
Joined: Jun 02, 2013 9:27
Location: Switzerland

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

Post by MrSwiss »

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: 1756
Joined: May 27, 2005 7:15
Location: FRANCE

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

Post by SARG »

@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: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

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

Post by counting_pine »

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: 1756
Joined: May 27, 2005 7:15
Location: FRANCE

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

Post by SARG »

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: 46
Joined: Feb 25, 2007 1:43
Location: N.Z.

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

Post by Manpcnin »

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: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

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

Post by counting_pine »

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.
Post Reply