Emfortran

106 views
Skip to first unread message

Zack Maril

unread,
Dec 24, 2011, 12:42:26 AM12/24/11
to emscripten-discuss
Here's what I've got so far:
https://github.com/zmaril/emscripten/blob/herecomesdrtran/emfortran

I decided to go the separate complier script route because dragonegg
has to call gcc instead of clang. There are also a whole different
setup for flags as far as I can tell. On my machine, I can get it to
the point where it successfully recognizes a fortran file, calls gcc
+dragon on it and output a file.

After that, all bets are off. I get errors like the following:
./emfortran tests/hello_world.f
(Emscripten: Running sanity checks)
WARNING: Closure compiler (/Users/zackmaril/Dev/closure-compiler/
compiler.jar) does not exist, check the paths in ~/.emscripten. -O2
and above will fail
0 llvm-nm 0x000000010f3c4702
1 llvm-nm 0x000000010f3c4b99
2 libsystem_c.dylib 0x00007fff91ebbcfa _sigtramp + 26
3 libsystem_c.dylib 0x00007fff6eeea250 _sigtramp +
18446744073122538864
4 llvm-nm 0x000000010f2ed7a1
5 llvm-nm 0x000000010f2ecfbf
6 llvm-nm 0x000000010f2ec594
7 llvm-nm 0x0000000000000002
Stack dump:
0. Program arguments: /Users/zackmaril/Projects/Ravascrip/clang
+llvm-3.0-x86_64-apple-darwin11/bin/llvm-nm /var/folders/dy/
7_v800lx5ss16j5m9yddq08m0000gn/T/tmpXloTLl/hello_world.o
/Users/zackmaril/Projects/Ravascrip/clang+llvm-3.0-x86_64-apple-
darwin11/bin/llvm-dis: Invalid bitcode signature
Traceback (most recent call last):
File "/Users/zackmaril/Projects/Ravascrip/emscripten/emscripten.py",
line 278, in <module>
temp_files.run_and_clean(lambda: main(keywords))
File "/Users/zackmaril/Projects/Ravascrip/emscripten/tools/
shared.py", line 188, in run_and_clean
func()
File "/Users/zackmaril/Projects/Ravascrip/emscripten/emscripten.py",
line 278, in <lambda>
temp_files.run_and_clean(lambda: main(keywords))
File "/Users/zackmaril/Projects/Ravascrip/emscripten/emscripten.py",
line 155, in main
args.infile = disassemble(args.infile)
File "/Users/zackmaril/Projects/Ravascrip/emscripten/emscripten.py",
line 66, in disassemble
if ret != 0: raise RuntimeError('Could not disassemble %s.' %
filepath)
RuntimeError: Could not disassemble /var/folders/dy/
7_v800lx5ss16j5m9yddq08m0000gn/T/tmpXloTLl/a.out.bc.
Traceback (most recent call last):
File "./emfortran", line 389, in <module>
final = shared.Building.emscripten(in_temp(target_basename +
'.bc'), append_ext=False)
File "/Users/zackmaril/Projects/Ravascrip/emscripten/tools/
shared.py", line 463, in emscripten
assert os.path.exists(filename + '.o.js') and len(open(filename +
'.o.js', 'r').read()) > 0, 'Emscripten failed to generate .js: ' +
str(compiler_output)
AssertionError: Emscripten failed to generate .js:

There are several different variations to this depending on the flags
that I include. I am still working through it, but I think it is
probably the right way to go in terms of architecture. There is a lot
of junk when you try to mix all the fortran code in with emcc or one
of the other files.

-Zack

Zack Maril

unread,
Dec 24, 2011, 1:18:08 AM12/24/11
to emscripten-discuss
Does emscripten use readable llvm or unreadable llvm?
Examples:
Readable llvm: https://gist.github.com/1516537
Unreadable llvm: https://gist.github.com/1516538

As far as I can tell, emcc works by emitting the unreadable llvm but I
just wanted to check before I moved ahead.
-Zack

Alon Zakai

unread,
Dec 24, 2011, 9:13:16 PM12/24/11
to emscripte...@googlegroups.com

My only concern in terms of architecture is that it looks like
emfortran is a copy-paste of emcc, with some modifications. It would
be nicer I think to share all the shared code somehow. There's
probably a nice way to add the fortran-related stuff to emcc itself
(but, obviously, get it working first ;)

- azakai

Alon Zakai

unread,
Dec 24, 2011, 9:18:35 PM12/24/11
to emscripte...@googlegroups.com
emcc can accept both human-readable LLVM assembly, or binary LLVM
bitcode. The suffix is important in emcc, if it sees .ll it assumes
assembly, if it sees .bc or .o it assumes bitcode. (emscripten.py does
the same, I think but am not sure.)

emcc will normally emit .js, unless called with -c in which case it
will emit .o with binary LLVM bitcode.

Note though that the unreadable file you show there doesn't look like
LLVM bitcode. LLVM bitcode starts with "BC" I think. Perhaps an
encoding issue though? Or maybe a native object file has been created
by mistake?

- azakai

Reply all
Reply to author
Forward
0 new messages