Thanks for doing the work of adding the changes to fbc, and putting them into Git too. I've merged both branches together and merged them into master. I think that should be fine, since I don't think the changes break anything else. We can improve it further as needed.

Check out symb-define.bas, specifically: https://github.com/freebasic/fbc/blob/1.07.2/src/compiler/symb-define.bas#L270 There is no __FB_DARWIN__, __FB_FREEBSD__,... on this file. It automatically defines a macro named __FB_<target_name>__, where <target_name> is the upper-case version of the name ...

Check out symb-define.bas, specifically: https://github.com/freebasic/fbc/blob/1 ... e.bas#L270

Looks pretty good, I think you've got most of it figured out already. One way to do/test it is probably something like this: - apply patches to normal fbc sources - build linux fbc which can now target solaris with the help of a linux-to-solaris gcc toolchain - build FB runtime library (rtlib) with ...

Checking whether llc --version works sounds interesting. Maybe it could even be used to decide which LLVM version to target, to adjust the code generation accordingly. If that doesn't work out for some reason, then yea, using clang only/always would certainly be easiest.

What is the correct way to translate a zero length array in a C struct to a FB type? You pass arrays of this type to certain functions, so they need to be the right size. True, it might be necessary to use only the header struct without a payload, so because of that it must have the same sizeof() a...

Last time I worked on this was, I think, around LLVM 3.2... the older release packages from llvm.org back then still included llc.exe. Nowadays it's not included for whatever reason, but it looks like you can get it from the llvm package in MSYS2 (might be using that because of MinGW-w64 anyways) or...

MrSwiss wrote:C:\DEV_TOOLS\FreeBASIC\source\FBFrog\src>c:\dev_tools\freebasic\1071_64\fbc *.bas -m FbFrog
It fails on: __FB_ARGC__

Maybe it works with -m fbfrog instead of -m FbFrog, unfortunately it seems that the -m option is case-sensitive (it needs to match the file name fbfrog.bas).

Yea pretty much that. Or maybe a test that checks whether a custom module-level constructor was invoked. (unless those are emitted in different sections than fb_hRtInit)

Maybe I can help out with this... fbc uses the same basic layout for structs and vtables as g++ (and msvc and COM), but some parts are skipped since FB doesn't support the full C++ features. Regarding fbc's vtable layout: https://github.com/freebasic/fbc/blob/1.06.0/src/compiler/symb-comp.bas#L150 F...

Wow, that's unfortunate... I wonder, does the fbc test suite already have a test case that would detect this?

If you would like to see the .asm file produced by fbc, there is an fbc command line option for that: -RR

for example: fbc -v -RR foo.bas
or: fbc -v -rr -m foo foo.bas

That should generate foo.asm next to foo.bas.

Yea go ahead, if I can help out a bit that's fine for me. I got no plans to make any big improvements though. For symbol naming conflicts usually the solution is to do something like declare function shell_ alias "shell" ... . There is an fbfrog option for that, -rename_ shell , or -rename...

Yea it allows # comments. The *.fbfrog files can also include others recursively, which can be useful to extract and reuse common parts.

No, it's unfinished, so not really useful. It's a mix of two ideas - 1) using libclang in fbfrog instead of a custom parser. Good, except it can't parse #define bodies, so it still needs some custom parsing for that. 2) making a "just-in-time bindgen" (for 1 target only instead of all targ...