C++ compiler fails when compile using -ecc option (__cdecl calling convention)

[crazii]

Code: ecc.cpp

#include <stddef.h>
#include <stdlib.h>

int main()
{
    return 0;
}

Command line:

wpp ecc.cpp -bt=dos -fr -ecc -fo=ecc.obj

Output

Open Watcom C++ x86 16-bit Optimizing Compiler
Version 2.0 beta Dec  1 2023 02:00:11 (64-bit)
Copyright (c) 2002-2023 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1989-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See https://github.com/open-watcom/open-watcom-v2#readme for details.
/home/crazii/watcom/h/cstddef(67): Error! E671: col(40) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstddef(67): Note! N393: col(40) included from /home/crazii/watcom/h/stddef.h(28)
/home/crazii/watcom/h/cstddef(67): Note! N393: col(40) included from output/ecc.cpp(1)
/home/crazii/watcom/h/cstdlib(302): Error! E671: col(41) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstdlib(310): Error! E671: col(46) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstdlib(318): Error! E671: col(40) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstdlib(351): Error! E671: col(38) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstdlib(377): Error! E671: col(41) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstdlib(378): Error! E671: col(47) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstdlib(379): Error! E671: col(43) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstdlib(380): Error! E671: col(46) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstdlib(381): Error! E671: col(57) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstdlib(382): Error! E671: col(59) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstdlib(400): Error! E671: col(47) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstdlib(401): Error! E671: col(40) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstdlib(415): Error! E671: col(49) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstdlib(416): Error! E671: col(48) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstdlib(417): Error! E671: col(48) function modifier cannot be used on a variable
/home/crazii/watcom/h/cstdlib(455): Warning! W211: col(35) #pragma attributes for 'stackavail' may be inconsistent
/home/crazii/watcom/h/cstdlib(452): Note! N392: col(28) definition: 'unsigned __watcall stackavail( void )'
/home/crazii/watcom/h/cstdlib(456): Warning! W211: col(36) #pragma attributes for '_stackavail' may be inconsistent
/home/crazii/watcom/h/cstdlib(453): Note! N392: col(28) definition: 'unsigned __watcall _stackavail( void )'
output/ecc.cpp: 110 lines, included 1535, 2 warnings, 16 errors

[pchapin]

I can confirm this issue. It is also an issue for wpp386 on my Windows 11 system. The -fr option doesn't seem to matter, only -ecc. In fact, this issue appears for all calling conventions except -ecw (i.e., the "Watcom" convention). Did this ever work?

[jmalak]

It looks like bug in calling convention classification in c++ compiler.
I don't know when it happen because C++ compiler tests don't contain test of these options.
Only C compiler tests check it.

[crazii]

Yes, wcc works OK.
-fr just prevent compiler generating a error log file. (.err)

[crazii]

This is the original owsetup.sh after installing ow2:

crazii@****:/$ cat ~/watcom/owsetenv.sh
#!/bin/sh
echo Open Watcom Build Environment
export PATH=/home/crazii/watcom/binl64:/home/crazii/watcom/binl:$PATH
export INCLUDE=/home/crazii/watcom/lh:$INCLUDE
export WATCOM=/home/crazii/watcom
export EDPATH=/home/crazii/watcom/eddat
export WIPFC=/home/crazii/watcom/wipfc
crazii@****:/$

But I didn't find any lh folder, so I changed it to h

During setup, I remember selected only 16 bit DOS, and then everything works fine with wmake wcc wpp wcc386 wpp386 , the built binary is working. Except that the compilation fails with -ecc option.

Yes, if native binaries are essential for targets, then it better force the installation, or give a warning.

I'll confirm if it works with default installation. But
I don't know if it is the same problem for @pchapin on Windows host, you can check it.

[jmalak]

Sorry you mixed two problems together.
Original issue with C++ compiler, it is discused here
Second problem with incorrect installation, related to missing lh sub-directory I moved it to issue #1247
Both issues are independent

[jmalak]

This is not related to issue but only note.
Your compiler command line is wrong.
For cross-compilation you must always specify target OS otherwise it is compiled for host OS.
Second problem is output object name, you specify it with .exe extension as executable but it is object file that should have .obj or .o extension as standard.
Correct command line should be
wpp -bt=dos ecc.cpp -fr -ecc -fo=ecc.obj

[crazii]

OK, cool.

ecc.cpp was another simple test case I created after I found the problem building my DOS targets, I did add -bt=dos with -ecc and it gets errors for my DOS targets.

So I created another simple test case ecc.cpp without -bt=dos, I think it should be added to avoid confusion - it is totally different without it.
-bt=dos added to the original issue description.
=fo changed to ecc.obj

[jmalak]

I don't understand why you use -ecc option because it is for special use.

[crazii]

I don't understand why you use -ecc option because it is for special use.

because I there was some functions being called by assembly, when I ported my code to ow2 (the code works for some other compilers with __cdecl as default), I just want to make sure there's not any bugs related to calling conventions so I could narrow down the problem.

The initial purpose using -ecc is just to avoid review/debug the code blindly to find the crash, it is useful when porting codes to ow2 . - if it works with -ecc, then I can take further steps to find the functions. if it doesn't then I will keep -ecc temporarily and skip the calling convention check and try to find the crash for other reasons, and after the crash is fixed, I will remove ecc again to the previous step.

then later I found that functions without __cdecl still works with assembly codes using stack to pass 1 or 2 parameters. I didn't read the programming guide carefully so I might be wrong about that.

Anyway my problem has been solved (multiple reason of crahses) and I've also checked the code carefully and added __cdecl for the functions with parameters called by assembly.

[jmalak]

-ecc change globaly all functions, except functions which have declared calling convention exactly.
If you need only some function you can use #pragma aux or __cdecl modifier for such function.
Below are examples how you can define cdecl calling convention specific per function not depending on -ec.. option.

void __cdecl func( void );

#pragma aux (__cdecl) func

[crazii]

yes I just wanted to globally change all, to narrow down the problem a bit as a first step. that why I used -ecc.

[jmalak]

Try to use -3s instead of -ecc it should works.

[crazii]

Cool, thanks for the tip, I forgot the register usage can be changed via command line. It might help me next time.
BUT Currently I'm writing code directly for ow2, not porting for it, so there will be less 'weird` problems/requests. LOL

[jmalak]

Take into account diference between -ecc and -3s (both use cdecl calling convention).
-ecc option switch calling convention to cdecl for all functions which has not defined calling convention explicitly without change C run-time library calling convention. By default it use C run-time library with parameters passed by registers (3r) for all CRTL functions. Generaly -ecc can be combined with -3r or -3s and it determine calling convention of used CRTL library.
On the other hand -3s change calling convention to cdecl for all including C run-time library calling convention (to cdecl). it uses C run-time library with parameters passed on stack (3s) for all functions and calling convention of CRTL cannot be changed unlike the -ecc option where CRTL calling convention can be changed.

[jmalak]

see issue #1068 , #1187 and #1246