Compilation cm3-boot-unix64le-d5.11.1-20210610.cpp failed for AMD64 Haiku

[DKnoto]

Hi,
After a long period of activity in trying to compile CM3 for AMD64/Haiku, today I made another attempt. I managed to fix a lot of problems but there are two left and the first one is irremovable at this point:

../src/builtinOps/Typecode.m3: At global scope:
../src/builtinOps/Typecode.m3:613: error: 'F_GETOWN' was not declared in this scope
../src/builtinOps/Typecode.m3:575: note: in definition of macro 'X'
../src/builtinOps/Typecode.m3:614: error: 'F_SETOWN' was not declared in this scope
../src/builtinOps/Typecode.m3:575: note: in definition of macro 'X'

The F_GETOWN and F_SETOWN flags are not currently supported in Haiku and are not in the fcntl.h file.

Unfortunately, you have to wait for the Haiku team to implement it.

Greetings.

[jaykrell]

We can probably just ifdef these in Uconstants.c. Assuming they aren't really used.
What are the other problems?

[DKnoto]

The second problem is M3_STATIC_ASSERT macro expansion:

cm3-boot-unix64le-d5.11.1-20210610.cpp:750:113: error: narrowing conversion of '-1' from 'int' to 'long unsigned int' [-Wnarrowing]
750 | #define M3_STATIC_ASSERT(expr) GCC_ATTRIBUTE_UNUSED typedef char M3PASTE(m3_static_assert, LINE)[(expr)?1:-1]
| ^
../src/unix/Common/Usignal.i3:98: note: in expansion of macro 'M3_STATIC_ASSERT'
cm3-boot-unix64le-d5.11.1-20210610.cpp:750:108: error: size '-1' of array 'm3_static_assert98' is negative
750 | #define M3_STATIC_ASSERT(expr) GCC_ATTRIBUTE_UNUSED typedef char M3PASTE(m3_static_assert, LINE)[(expr)?1:-1]
| ~~~~~~^~~~~
../src/unix/Common/Usignal.i3:98: note: in expansion of macro 'M3_STATIC_ASSERT'
cm3-boot-unix64le-d5.11.1-20210610.cpp:750:113: error: narrowing conversion of '-1' from 'int' to 'long unsigned int' [-Wnarrowing]
750 | #define M3_STATIC_ASSERT(expr) GCC_ATTRIBUTE_UNUSED typedef char M3PASTE(m3_static_assert, LINE)[(expr)?1:-1]
| ^
../src/unix/Common/Usignal.i3:156: note: in expansion of macro 'M3_STATIC_ASSERT'
cm3-boot-unix64le-d5.11.1-20210610.cpp:750:108: error: size '-1' of array 'm3_static_assert156' is negative
750 | #define M3_STATIC_ASSERT(expr) GCC_ATTRIBUTE_UNUSED typedef char M3PASTE(m3_static_assert, LINE)[(expr)?1:-1]
| ~~~~~~^~~~~
../src/unix/Common/Usignal.i3:156: note: in expansion of macro 'M3_STATIC_ASSERT'
cm3-boot-unix64le-d5.11.1-20210610.cpp:750:113: error: narrowing conversion of '-1' from 'int' to 'long unsigned int' [-Wnarrowing]
750 | #define M3_STATIC_ASSERT(expr) GCC_ATTRIBUTE_UNUSED typedef char M3PASTE(m3_static_assert, LINE)[(expr)?1:-1]
| ^
../src/unix/Common/Usignal.i3:173: note: in expansion of macro 'M3_STATIC_ASSERT'
cm3-boot-unix64le-d5.11.1-20210610.cpp:750:108: error: size '-1' of array 'm3_static_assert173' is negative
750 | #define M3_STATIC_ASSERT(expr) GCC_ATTRIBUTE_UNUSED typedef char M3PASTE(m3_static_assert, LINE)[(expr)?1:-1]
| ~~~~~~^~~~~
../src/unix/Common/Usignal.i3:173: note: in expansion of macro 'M3_STATIC_ASSERT'
../src/unix/Common/Usignal.i3: In function 'int SockAddrM3ToNativeUn(const m3_sockaddr_un*, sockaddr_un*)':
cm3-boot-unix64le-d5.11.1-20210610.cpp:750:113: error: narrowing conversion of '-1' from 'int' to 'long unsigned int' [-Wnarrowing]
750 | #define M3_STATIC_ASSERT(expr) GCC_ATTRIBUTE_UNUSED typedef char M3PASTE(m3_static_assert, LINE)[(expr)?1:-1]
| ^
../src/unix/Common/Usignal.i3:244: note: in expansion of macro 'M3_STATIC_ASSERT'
cm3-boot-unix64le-d5.11.1-20210610.cpp:750:108: error: size '-1' of array 'm3_static_assert244' is negative
750 | #define M3_STATIC_ASSERT(expr) GCC_ATTRIBUTE_UNUSED typedef char M3PASTE(m3_static_assert, LINE)[(expr)?1:-1]
| ~~~~~~^~~~~
../src/unix/Common/Usignal.i3:244: note: in expansion of macro 'M3_STATIC_ASSERT'
../src/unix/Common/Usignal.i3: In function 'int SockAddrNativeToM3Un(const sockaddr_un*, m3_sockaddr_un*)':
cm3-boot-unix64le-d5.11.1-20210610.cpp:750:113: error: narrowing conversion of '-1' from 'int' to 'long unsigned int' [-Wnarrowing]
750 | #define M3_STATIC_ASSERT(expr) GCC_ATTRIBUTE_UNUSED typedef char M3PASTE(m3_static_assert, LINE)[(expr)?1:-1]
| ^
../src/unix/Common/Usignal.i3:259: note: in expansion of macro 'M3_STATIC_ASSERT'
cm3-boot-unix64le-d5.11.1-20210610.cpp:750:108: error: size '-1' of array 'm3_static_assert259' is negative
750 | #define M3_STATIC_ASSERT(expr) GCC_ATTRIBUTE_UNUSED typedef char M3PASTE(m3_static_assert, LINE)[(expr)?1:-1]
| ~~~~~~^~~~~
../src/unix/Common/Usignal.i3:259: note: in expansion of macro 'M3_STATIC_ASSERT'

[jaykrell]

Get/setown: 7fe42fc

static_assert: These error messages are bad, sorry.
I think I can fix them, by having every hand written .c file have a line directive at start, inserted automatically.

Or, maybe try:
https://github.com/modula3/cm3/releases/tag/d5.11.4

That should isolate the errors.

[DKnoto]

Is there a single CPP file available for version d5.11.4?

[jaykrell]

static assert 98 maybe:

C:\s\cm3\m3-libs\m3core\SPARC64_LINUX\Usocket.c(98):M3_STATIC_ASSERT(sizeof(m3_sockaddr_un) >= sizeof(sockaddr_un));

Please show us sockaddr_un ?

We imagine it looks like this:

// Idealized Modula3 Unix socket address.
// This is likely slightly larger than all native forms.
// if not make it larger, e.g. 256 - 2.
// Sometimes family is 8 bits adjacent to another 8 bits.
struct m3_sockaddr_un
{
unsigned short family;
char path[128 - 2];
};
M3_STATIC_ASSERT(sizeof(m3_sockaddr_un) == 128);

but yours is larger.
Comment says we can just make it larger.
Maybe we can remove type entirely, maybe.

For the others the line numbers have drifted I maybe check old commit..
but please try that release instead, it'll give much better errors.

You can also remove all the line directives from the large file,
recompile, and then look at the lines in the file with the errors.

Sorry this is a bit difficult.

Do you need the single file form? I realize it has advantages, but it is tradeoff.
Is cmake or python3 unavailable?
Make? GNU make? sh? (autotools output works?)

We have a cmake-less multi-file form too. I can prepare that. With or without autotools.

[DKnoto]

I have Python3 3.7.12 and CMake 3.21.3. I'm going to work with version d5.11.4 ;-)

[DKnoto]

In Haiku sockaddr_un looks like:

`/*

• Copyright 2006-2012 Haiku, Inc. All Rights Reserved.
• Distributed under the terms of the MIT License.
  */
  #ifndef _SYS_UN_H
  #define _SYS_UN_H

#include <sys/socket.h>

struct sockaddr_un {
uint8_t sun_len;
uint8_t sun_family;
char sun_path[126];
};

#endif /* _SYS_UN_H */
`

[jaykrell]

That looks like it matches Modula-3.
Let's wait for all the "cmake errors".

[DKnoto]

Yes, I wrote code:
`
#include <inttypes.h>
#include <stdio.h>

struct sockaddr_un {
uint8_t sun_len;
uint8_t sun_family;
char sun_path[126];
};

int main(void)
{
printf("sizeof(sockaddr_un) == %" PRIu64 "\n", sizeof(sockaddr_un));
return 0;
}
`
and size is 128.

[DKnoto]

In macro M3_STATIC_ASSERT I temporarily changed [(expr)?1:-1] to [(expr)?1:0]. Compilation of d5.11.1 works fine but unfortunately cm3 executable does not work. I catch runtime error:

`

---

*** runtime error:
*** An enumeration or subrange value was out of range.
*** file "../src/os/POSIX/OSErrorPosix.m3", line 50

---

Abort
`

[jaykrell]

I guess change the == to >=.

[jaykrell]

Please consider getting me ssh/scp access.

[DKnoto]

I run Haiku on the Qemu virtual machine on Linux. Single file is more convenient for me, I created a git repository with Makefile and cm3.cpp. Editing with vim isn't convenient, but it's also not very difficult. The first time I tried I had problems with memory, 4 GB of RAM forced the use of the swap file and made the compilation process take a long time. After upgrading to 8GB, it takes about 5 minutes to compile.

My build options:
`
####### Files

TARGET = cm3

SOURCES =
cm3.cpp

OBJECTS =
cm3.o

####### Compiler options

CXXFLAGS = -std=c++17 -fPIC -pipe
CXXFLAGS += -m64
CXXFLAGS += -Os -g

CFLAGS = $(CXXFLAGS)

INCDIR =
-I/boot/system/develop/headers
-I/boot/system/develop/headers/private/libs/compat/freebsd_network/compat/

LIBDIR =

LDFLAGS =
-lbe -lnetwork

####### Implicit rules

.SUFFIXES: .c .cpp .s

.c.o:
$(CC) $(INCDIR) $(CFLAGS) -c $&lt;

.cpp.o:
$(CXX) $(INCDIR) $(CXXFLAGS) -c $&lt;

####### Build rules

all: $(TARGET)

$(TARGET): $(OBJECTS)
$(CXX) $(LIBDIR) $(LDFLAGS) $(OBJECTS) -o $(TARGET)

`

Unfortunately, I cannot provide an SSH connection. I am connected to the network via LTE and my provider does not allow external connections.

[DKnoto]

I corrected the definition of the M3_STATIC_ASSERT macro properly for c ++ 17:
`
#define M3PASTE_(a, b) a##b
#define M3PASTE(a, b) M3PASTE_(a, b)

#define M3STRINGIZE_(a) # a
#define M3STRINGIZE(a) M3STRINGIZE_(a)

#define M3_STATIC_ASSERT(expr) static_assert(expr, M3STRINGIZE(M3PASTE(m3_static_assert, LINE)));
`

[DKnoto]

I am checking only four assertions now.

[DKnoto]

I originally had these warnings:

[dknoto@hms005 cm3-d5.11.3]$ make
g++ -I/boot/system/develop/headers -I/boot/system/develop/headers/private/libs/compat/freebsd_network/compat/ -std=c++17 -fPIC -pipe -m64 -Os -g -c cm3.cpp
../src/Wrx86.m3:6514: error: static assertion failed: m3_static_assert6514
cm3.cpp:759:46: note: in definition of macro 'M3_STATIC_ASSERT'
759 | #define M3_STATIC_ASSERT(expr) static_assert(expr, M3STRINGIZE(M3PASTE(m3_static_assert, LINE)));
| ^~~~
../src/Wrx86.m3:6531: error: static assertion failed: m3_static_assert6531
cm3.cpp:759:46: note: in definition of macro 'M3_STATIC_ASSERT'
759 | #define M3_STATIC_ASSERT(expr) static_assert(expr, M3STRINGIZE(M3PASTE(m3_static_assert, LINE)));
| ^~~~
../src/Wrx86.m3: In function 'int SockAddrM3ToNativeUn(const m3_sockaddr_un*, sockaddr_un*)':
../src/Wrx86.m3:6607: error: static assertion failed: m3_static_assert6607
cm3.cpp:759:46: note: in definition of macro 'M3_STATIC_ASSERT'
759 | #define M3_STATIC_ASSERT(expr) static_assert(expr, M3STRINGIZE(M3PASTE(m3_static_assert, LINE)));
| ^~~~
../src/Wrx86.m3: In function 'int SockAddrNativeToM3Un(const sockaddr_un*, m3_sockaddr_un*)':
../src/Wrx86.m3:6623: error: static assertion failed: m3_static_assert6623
cm3.cpp:759:46: note: in definition of macro 'M3_STATIC_ASSERT'
759 | #define M3_STATIC_ASSERT(expr) static_assert(expr, M3STRINGIZE(M3PASTE(m3_static_assert, LINE)));
| ^~~~
../src/Wrx86.m3: In function 'int SockAddrNativeToM3(const NativeSockAddrUnionAll*, M3SockAddrUnionAll*)':
../src/Wrx86.m3:6678: warning: control reaches end of non-void function [-Wreturn-type]
Makefile:90: recipe for target 'cm3.o' failed
make: *** [cm3.o] Error 1

[DKnoto]

With the removal of the #line directives, the situation has definitely improved:

g++ -I/boot/system/develop/headers -I/boot/system/develop/headers/private/libs/compat/freebsd_network/compat/ -std=c++17 -fPIC -pipe -m64 -Os -g -c cm3.cpp
cm3.cpp:4894117: error: static assertion failed: m3_static_assert4894117
4894117 | M3_STATIC_ASSERT(sizeof(m3_sockaddr_in) == sizeof(sockaddr_in));
|
cm3.cpp:759:46: note: in definition of macro 'M3_STATIC_ASSERT'
759 | #define M3_STATIC_ASSERT(expr) static_assert(expr, M3STRINGIZE(M3PASTE(m3_static_assert, LINE)));
| ^~~~
cm3.cpp:4894134: error: static assertion failed: m3_static_assert4894134
4894134 | M3_STATIC_ASSERT(M3_FIELD_SIZE(m3_sockaddr_un, path) > M3_FIELD_SIZE(sockaddr_un, sun_path));
|
cm3.cpp:759:46: note: in definition of macro 'M3_STATIC_ASSERT'
759 | #define M3_STATIC_ASSERT(expr) static_assert(expr, M3STRINGIZE(M3PASTE(m3_static_assert, LINE)));
| ^~~~
cm3.cpp: In function 'int SockAddrM3ToNativeUn(const m3_sockaddr_un*, sockaddr_un*)':
cm3.cpp:4894210: error: static assertion failed: m3_static_assert4894210
4894210 | M3_STATIC_ASSERT(sizeof(native->sun_path) < sizeof(m3->path));
|
cm3.cpp:759:46: note: in definition of macro 'M3_STATIC_ASSERT'
759 | #define M3_STATIC_ASSERT(expr) static_assert(expr, M3STRINGIZE(M3PASTE(m3_static_assert, LINE)));
| ^~~~
cm3.cpp: In function 'int SockAddrNativeToM3Un(const sockaddr_un*, m3_sockaddr_un*)':
cm3.cpp:4894226: error: static assertion failed: m3_static_assert4894226
4894226 | M3_STATIC_ASSERT(sizeof(native->sun_path) < sizeof(m3->path));
|
cm3.cpp:759:46: note: in definition of macro 'M3_STATIC_ASSERT'
759 | #define M3_STATIC_ASSERT(expr) static_assert(expr, M3STRINGIZE(M3PASTE(m3_static_assert, LINE)));
| ^~~~
cm3.cpp: In function 'int SockAddrNativeToM3(const NativeSockAddrUnionAll*, M3SockAddrUnionAll*)':
cm3.cpp:4894281: warning: control reaches end of non-void function [-Wreturn-type]
4894281 | }
|
Makefile:90: recipe for target 'cm3.o' failed
make: *** [cm3.o] Error 1

[DKnoto]

I have four static asserts:

4894117 | M3_STATIC_ASSERT(sizeof(m3_sockaddr_in) == sizeof(sockaddr_in));
4894134 | M3_STATIC_ASSERT(M3_FIELD_SIZE(m3_sockaddr_un, path) > M3_FIELD_SIZE(sockaddr_un, sun_path));
4894210 | M3_STATIC_ASSERT(sizeof(native->sun_path) < sizeof(m3->path));
4894226 | M3_STATIC_ASSERT(sizeof(native->sun_path) < sizeof(m3->path));

We need to match the conversion from the native Haiku to the native M3 and vice versa. But is it used by the compiler?

[jaykrell]

But is it used by the compiler?

You are correct: We are building all of m3core/libm3, even though the compiler does not use all of their code.
We could put some sort of ifndef boot around here and assert(false), but we'd want to build a full m3core/libm3 shortly thereafter.
Interesting idea though to trim the bootstrap. Another idea though is to pass through the bootstrap more, rebuild less natively.

[DKnoto]

In Linux this field has 108 bytes.

[DKnoto]

#define UNIX_PATH_MAX 108

struct sockaddr_un {
__kernel_sa_family_t sun_family; /* AF_UNIX /
char sun_path[UNIX_PATH_MAX]; / pathname */
};

[jaykrell]

Linux: We don't need to know the exact size.
We need a number that is the same size or larger than "all" systems.
My mistake was I missed the "same" part.
So we can safely copy the native data to Modula-3 without truncation.
I guess you might worry about truncation in the other direction.
But, thing is, the system is only very lightly ifdefed. I try to come up with "very" portable forms where I can and ifdef as a last resort.
Perhaps we should use autoconf and probe the exact size and generate headers at install time. Perhaps.

In olden times we really did duplicate the native types exactly, in the .i3 files.
It was super tedious and expensive and error prone for no significant gain.
I repeatedly had stack overflows because I had mistranslated struct stat.
Now we go through portable C source and porting is vastly less work.

[DKnoto]

I understand.

[DKnoto]

BTW. Do you want my patches for cm3-boot-unix64le-d5.11.3 - *. cpp?

[DKnoto]

What version of the system have you installed? I have hrev55767.

[jaykrell]

Python3's uuid.getnode gets the MAC address so that is a lead.
That is the lead I followed on HP-UX successfully.
Python itself runs a bunch of commands and searches.
I am inclined just to run Python3 then.

[jaykrell]

I installed from the beta3 .iso.
On Windows/x86 cdecl and stdcall have meaning, I understand well.
I have never run into another system with multiple calling conventions and so where they matter.
Well, I guess old Apple IIGS and Mac/68K had multiple calling conventions.
We are unlikely to support them ever.

Does Haiku/x86 have multiple calling conventions?
Does anyone care to support Haiku/x86?
'cause we can just undef cdecl and define it to empty.
Or use another symbol rather than break that one (or break it after all the includes).

I was vaguely aware of this problem, though.
In that Msvc has __cdecl and it works on functions and function pointers, placed correctly.
gcc for Windows/x86 has define __cdecl attribute(cdecl) but it doesn't work the same on function pointers. Maybe it has to be placed differently.

The reason I sprinkle cdecl all around is maybe moot.
It is in case someone compiles with -Gz or whatever -- there are switches to change the default calling convention to fastcall or stdcall.
The idea is, that might be ok for their code, but for Modula-3 we want consistency, and the headers compiled in alternate ways, to describe libs that only compiled one way.

We could omit cdecl and require never to use -Gz or whatever.
Not like there are many 32bit x86 Windows/Haiku users anyway, and sticking to default short command lines isn't terrible guidance.

Vim/pkgman: Thank you!
HaikuDepot didn't seem to have ncurses_devel that the instructions suggested.

Thoughts?

[DKnoto]

Beta3 is a 32 bit system I suppose. This one ensures compatibility with the outdated BeOS.

[jaykrell]

~> uname -a
Haiku shredder 1 hrev55181+62 Jan  8 2022 09:08: x86_64 x86_64 Haiku

[DKnoto]

Vim is in Haiku:
$ pkgman search/install vim

[jaykrell]

boot1.py not boot1c.txt.

[DKnoto]

$ ./boot1.py amd64_haiku
Traceback (most recent call last):
File "./boot1.py", line 27, in
import pylib
File "/Works/Projekty/CM3/cm3-github/scripts/python/pylib.py", line 600, in
for a in os.popen(CM3 + " -version 2>" + DevNull):
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

[jaykrell]

oh there is a readme.
Try:
./boot1.py amd64_haiku
?

[jaykrell]

boot1c.txt is how to build the single file bootstrap, which isn't needed..and is cumbersome when it doesn't work.
boot1.py and boot1autotools.py build more traditional easier to work with many file bootstraps.
boot1.py has a Makefile that it tries to adapt to the specified system. You should look at its top.
boot1autotools.py uses autoconf/automake and I don't remember if I tried it on Haiku yet.
Please report any errors.

[jaykrell]

TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

I see this like when cm3 does not exist or does not start.
Does cm3 or cm3 -version work?
Maybe if you say ./boot1.py amd64_haiku it skips cm3 -version, i.e. no more fishing for host to default target?

[DKnoto]

Please slowly ;-)
I have an old cm3 version that keeps crashing. Probably I will need a single cpp file generated from master and as I understand it I will not get this file without a working cm3?

[DKnoto]

With an empty cm3.cfg file my version works but I don't have your corrections there:
./cm3 --version | grep -v dbg
Critical Mass Modula-3 version d5.11.3
GitInfo: https://github.com/coder5506/cm3/commit/7c767c906c18cff9dc9987988c2b01a373b8b999
https://github.com/coder5506/cm3/commits/master
remote: https://github.com/coder5506/cm3
revision: 7c767c9
branch: master
last updated: 2021-06-23
compiled: 2022-01-13 19:48:59
configuration: ./cm3.cfg
host: AMD64_HAIKU
target:

[jaykrell]

In pylib.py, this code:

Host = None
for a in os.popen(CM3 + " -version 2>" + DevNull):
    if (StringContains(a, "Critical Mass Modula-3 version 5.1.")
     or StringContains(a, "Critical Mass Modula-3 version 5.2.")
     or StringContains(a, "Critical Mass Modula-3 version d5.5.")):
        if env_OS == "Windows_NT":
            Host = "NT386"
            break
    if StringContains(a, "host:"):
        Host = a.replace("\r", "").replace("\n", "").replace(" ", "").replace("host:", "")
        break

Change it to just:

Host = "AMD64_HAIKU"

?
I will try removing this code entirely.

But there is the point, that to build the bootstrap
you do need a working cm3. Like on Linux, Windows, Mac, BSD, etc.
It certainly doesn't have to be on Haiku.
All new systems are "crossed" to.
Nevermind that bootstraps are now generally portable across systems..you can just say:

./boot1.py amd64_linux
or
./boot1autotools.py amd64_linux

and the result should work on Haiku. ("64bit little endian Unix").

You shouldn't need the single file bootstrap.
These others give you a tgz that should work.

[DKnoto]

Add AMD64_HAIKU to .gitignore, I can't do that.

[DKnoto]

Success, I have *.cpp files in cm3-boot-AMD64_HAIKU-d5.11.8-20220117 directory :-)

[DKnoto]

Full success. I did the [scripts/python]$ ./do-cm3-min.py buildship. My test software compiled and runs on Haiku :-)
Haiku-55787-CM3-d5.11.8-Stupid.png

[jaykrell]

Good!
The cdecl warnings should be fixed.
Please try master.
7f5cb55

i.e try .\upgrade.py
or upgrade-full.sh
you can add the parameters amd64_haiku c just case.

[DKnoto]

I have full version of CM3 on Haiku! Warnigs still exists.

[DKnoto]

Hi Jay, I have three more minor matters:

• Can I do a pull-requests? I would like to eliminate this annoying warning while building the compiler and during program execution;
• Are unit tests performed when building the compiler, and if so, for what part of the code?
• What happened to the performance? Does the -O or -O3 option work? My simple test algorithm is slower than C/C ++ code, which does not surprise me too much, but it is worse than Java/JVM and C#/.Net and even Rust, which worried me a lot.

[VictorMiasnikov]

• Are unit tests performed when building the compiler, and if so, for what part of the code?

There are they:
m3-sys/m3tests/

Example:
https://github.com/esessoms/cm3/commit/804a7c5b1f4a057c47fff56418683f07366beb83
( ^^^^^^^^^^^^^ Outdated on 2022-09-20 -( )

( You can see it in CI/CD as "formatted in more visual style":

a)
https://github.com/esessoms/cm3/actions
https://github.com/esessoms/cm3/runs/4734625936?check_suite_focus=true

b) ( another commit)
https://app.circleci.com/pipelines/github/modula3/cm3/24/workflows/8b7fd951-e232-4429-ba3e-98f122b15c9c/jobs/23
)

[DKnoto]

Many thanks for the explanation. My test program is very simple. I will try to manually tweak the output code to be comparable to the performance in C/C++ and see what is really going on there.

[jaykrell]

The output C/C++ code is horrible, unreadable, not idiomatic, sorry. Kinda by design..due to the level it is implemented it..which is probably not ideal. It should probably be moved up to m3front. There are problems I need to fix.
Specifically local variables get overly uniquely named. And records are not debuggable. First is mostly fixable and second is totally fixable. Sorry it is taking so long.

[DKnoto]

I know this code is terrible to read, but I've already read it a bit when I ran the cm3.cpp compilation ;-)

[DKnoto]

I was able to manually compile the main part of the algorithm with g ++. With the -O3 and -march = corei7 optimization options added, the execution time is slightly worse than in C ++ code. I'll work on that.