I just wanted to test libfirm with cparser, but I was not able to build libfirm. The Makefile returns early with:

russel ~/w/c/libfirm % make
GEN build/gen/include/libfirm/nodes.h
Traceback (most recent call last):
  File "/home/weigl/work/cparser/libfirm/./scripts/gen_ir.py", line 9, in <module>
    from jinja2 import Environment
  File "/home/weigl/work/cparser/libfirm/scripts/jinja2/__init__.py", line 33, in <module>
    from jinja2.environment import Environment, Template
  File "/home/weigl/work/cparser/libfirm/scripts/jinja2/environment.py", line 13, in <module>
    from jinja2 import nodes
  File "/home/weigl/work/cparser/libfirm/scripts/jinja2/nodes.py", line 19, in <module>
    from jinja2.utils import Markup
  File "/home/weigl/work/cparser/libfirm/scripts/jinja2/utils.py", line 527, in <module>
    from markupsafe import Markup, escape, soft_unicode
  File "/home/weigl/work/cparser/libfirm/scripts/markupsafe/__init__.py", line 13, in <module>
    from collections import Mapping
ImportError: cannot import name 'Mapping' from 'collections' (/usr/lib64/python3.10/collections/__init__.py)
make: *** [Makefile:144: build/gen/include/libfirm/nodes.h] Error 1

I could track it down to the Python scripts in ./scripts and the included libraries.
I am using Python 3.10, but it seems that collections.Mapping was moved to collections.abc. The move was done at Python 3.5 or before.

Tried solutions:

1. Downgrade to Python 2.7 but then it fails for a different reason

ImportError: No module named machinery
make: *** [Makefile:144: build/gen/include/libfirm/nodes.h] Error 1

2. Remove out-dated included version of jinja2 and marksafe, then it failed due to missing module:

ModuleNotFoundError: No module named 'jinja2._compat'
make: *** [Makefile:144: build/gen/include/libfirm/nodes.h] Error 1

Fix can be easily fixed, see this patch:

diff --git a/scripts/irops.py b/scripts/irops.py
index b9ca48cc0..943461456 100644
--- a/scripts/irops.py
+++ b/scripts/irops.py
@@ -1,9 +1,8 @@
 from jinjautil import export_filter, export
-from jinja2._compat import string_types
+#from jinja2._compat import string_types
 from filters import arguments
 import sys
 
-
 class Node(object):
     '''Node base class'''
     only_regular = False
@@ -122,7 +121,7 @@ def setnodedefaults(node):
     # as a list of (name, comment) tuples. Normalize it to Input objects
     new_ins = []
     for i in node.ins:
-        if isinstance(i, string_types):
+        if isinstance(i, str):
             i = Input(i)
         elif isinstance(i, tuple):
             i = Input(name=i[0], comment=i[1])
@@ -131,7 +130,7 @@ def setnodedefaults(node):
     if hasattr(node, "outs"):
         new_outs = []
         for o in node.outs:
-            if isinstance(o, string_types):
+            if isinstance(o, str):
                 o = Output(o)
             elif isinstance(o, tuple):
                 o = Output(name=o[0], comment=o[1])

Then libfirm successfully compiles.

test

http://libfirm.org/ redirects to a 404.

There's a paper about PBQP based Instruction Selection. But I can't find it in libfirm's codebase. Why it is not merged in libfirm? What are the reasons?

¿ is a good idea to compile C to C ?
I think this is a way to have cparser in miriad of small processors ( z8 encore, stm8, etc ), and assemblers and linkers are available.
A functional backend to emit ANSI C can be the best documented way a backend may have, libfirm has a TEMPLATE backend, but the way from this template to a working backend needs long learning wave. C programmers are used to read C code without docs, so make a new backend from this can be easier.

I created a custom backend using the provided template. While it compiles properly I am unable to invoke it. If I just call it the error message tells me it is looking for my-target-gcc, which it can not find.
If I try to provide the target triple itself it can also not find it.
This is also true for existing backends.

I wasn't able to find any guide or docs for this. Could you help me understand how to get this to work?

Thanks.

In my efforts to try and build fluffy (which haven't been going too well), I attempted to throw sudo make install at libfirm's Makefile, and was greeted with

make: *** No rule to make target `install'.  Stop.

Huh.

Looking around and wondering what to do next, I noticed CMakeLists.txt. Aha!

Or not:

$ cmake .
-- Configuring done
-- Generating done
-- Build files have been written to: /home/i336/libfirm
$ make
[  1%] Generating gen/ir/be/TEMPLATE/gen_TEMPLATE_new_nodes.c.inl
Fatal error: Could not open /home/i336/libfirm/gen/ir/be/TEMPLATE/gen_TEMPLATE_new_nodes.c.inl, reason: No such file or directory
make[2]: *** [gen/ir/be/TEMPLATE/gen_TEMPLATE_new_nodes.c.inl] Error 2
make[1]: *** [CMakeFiles/firm.dir/all] Error 2
make: *** [all] Error 2

Apparently the cmake build-file generates a broken Makefile. I had a look at it, but I don't understand the structure of the project, so the necessary changes are beyond me (it seems to me that the project's directory structure changed at somepoint, and CMakeLists.txt wasn't updated).

I don't consider this a blocking or breaking issue, because it's not affecting libfirm's functionality; I only discovered this while trying to build fluffy (which currently isn't working in any case). That said, I'd remove CMakeLists.txt, if just for the time being, and possibly add an install target to the Makefile :P

PS. This is an awesome project. FYI, cparser built fine and appears to chomp .c files happily - why on earth doesn't everyone know about this 3.7MB C++ compiler?! ^^

It would be great if firm produced code for WebAssembly. Currently, only LLVM and Binaryen can do this. But LLVM is too huge, and Binaryen mostly good for low-level optimization of the wasm stack machine, but weak in intermediate speculative optimizations. Firm could be a good alternative.

$ make
...
LINK build/debug/libfirm.so
build/debug/ir/common/timing.o: In function _time_get': C:\msys64\work\libfirm/ir/common/timing.c:134: undefined reference to __imp_timeGetTime'
build/debug/ir/stat/statev.o: In function key_matches': C:\msys64\work\libfirm/ir/stat/statev.c:41: undefined reference to regexec'
build/debug/ir/stat/statev.o: In function stat_ev_begin': C:\msys64\work\libfirm/ir/stat/statev.c:198: undefined reference to regcomp'
build/debug/ir/stat/statev.o: In function stat_ev_end': C:\msys64\work\libfirm/ir/stat/statev.c:218: undefined reference to regfree'
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:154: build/debug/libfirm.so] Error 1

And here is fix:

vi Makefile +55
LINKFLAGS += $(LINKFLAGS_$(variant)) -lm -lwinmm -lregex

get_method_n_params return a size_t but new_Call (and variants) takes an int for the arity.
Proposed fix: set get_method_n_params return type to int.

I have to manually add

#include "firm_types.h"
#include "stddef.h"

#include "begin.h"
...
#include "end.h"

in the nodes.h that i get after make.

hello,

It seems there is some confusion about what are the project's terms and conditions.
The COPYING file says that the license is LGPL, but most files have a GPLv2 header.

You can easilly get a list of the files with GPLv2 headers with (GNU grep below)

grep -l - R -m1 "GPL" ir/

and for LGPL -- which most of it is ir/libcore/ except for lc_opts_enum.c -- with

grep -l -R -m1 "GNU Lesser" ir/

Just playing around with some introductory examples. In my parser, I don't parse numeric constants beyond their tokens and elect keep them as strings, which is great because new_integer_tarval_from_str() exists.

Doing a simple tarval_sub() and then tarval_is_negative() tends to work fine - except for when the tarval is really long.

The following program outputs 0 when it really should output 1 (smaller values correctly show 1):

extern "C" {
#include "./libfirm/include/libfirm/firm.h"
}

#include <cassert>
#include <iostream>

int main() {
	ir_init();

	ir_tarval *a = new_integer_tarval_from_str("10", 2, 0, 10, mode_Is);
	assert(a != get_tarval_bad());
	ir_tarval *b = new_integer_tarval_from_str("37465772635463726354918273645536475", 35, 0, 10, mode_Is);
	assert(b != get_tarval_bad());
	ir_tarval *c = tarval_sub(a, b);
	assert(c != get_tarval_bad());
	std::cout << tarval_is_negative(c) << std::endl;
	return 0;
}

0

Am I missing something, or is there a limit in tarval length? Shouldn't I be getting get_tarval_bad() here (and thus a failed assertion)? Do tarvals overflow?

Commit is 6dabd82.

The online demo http://kreacher.isla-de-muerta.de/~matze/online_compiler seems to be defunct and the download links point to some other git repo, not the one on GitHub

Mapping lives in collections.abc now. Patch produced by git against libfirm b7f2ed7 attached
Python-3.11-Markup.txt

Hi,

I just wanted to let the maintainers know that today we shut down pp.ipd.kit.edu/git/{libfirm,cparser,...} because of annoyances wrt. logging and spiders.
I don't think that mirroring has been working for the past 2 years at least, so you should hardly notice.

We will also "soon" let https://pp.ipd.kit.edu/ rot, because at the end of 2024 nobody will be there to maintain the page any longer.

The issue with install -d is that if the given directory already exists, it is nonetheless given the same mode as the parent directory. This is undesirable in various circumstances (in particular on my macOS system). Thus, being less obtrusive, I think that mkdir -p is preferable.

I'd be happy to create a PR for this if it makes sense to you too.