Compile llvm-gcc fortran backend using mingw

Hello everyone!

I got following error while trying to compile llvm-gcc-4.2 using mingw:

…\llvm-gcc-4.2\obj\libcpp/…/…/libcpp/macro.c:1165:
undefined reference to flag_iasm_blocks' stub-c.o:stub-c.c:(.debug_info+0x81a0): undefined reference to flag_iasm_blocks’
stub-c.o:stub-c.c:(.debug_info+0x81b9): undefined reference to iasm_state' stub-c.o:stub-c.c:(.debug_info+0x81d8): undefined reference to iasm_in_operands’

Configuration command:

…/configure --enable-languages=,c++,fortran --prefix=u:/libs/llvm-gcc-2.9 --program-prefix=llvm- --enable-llvm=u:/libs/llvm-2.9 --disable-bootstrap --disable-multilib

LLVM itself was compiled & installed successfully with such configuration:
…/configure --prefix=u:/libs/llvm-2.9 --enable-optimized --enable-assertions

I tried latest sources from SVN and from official download page - result is the same.
I followed few guides on compilation(including official one) - same.

MinGW has gcc 4.6.1 and it seems all required packages (binutils, perl, gfortran, mpfr, gmp, etc) are installed.

I would appreciate any help on how to solve this problem.

Thank you in advance.
Pavel.

P.S.
BTW, it is little bit strange that llvm-gcc doesn’t support CMake building system.
LLVM does and it is extremely convenient…

Hi Pavel,

BTW, it is little bit strange that llvm-gcc doesn't support CMake building system.
LLVM does and it is extremely convenient....

llvm-gcc is dead, deprecated in favour of clang and dragonegg. It won't be part
of the upcoming 3.0 release. This is why no-one is interested in working on it.

Ciao, Duncan.

Thank you for quick reply.

I see, llvm-gcc is frozen…

Is there Fortran front-end for LLVM then?

Hi Pavel,

Is there Fortran front-end for LLVM then?

yes, dragonegg: http://dragonegg.llvm.org
The development version (i.e. the upcoming 3.0 release) works better than
llvm-gcc ever did.

Ciao, Duncan.

Dear Duncan,

I appreciate your help. Thank you!

Best,
Pavel Holoborodko

The tentative release notes still say otherwise: "LLVM 3.0 will be the last release of llvm-gcc." (http://llvm.org/docs/ReleaseNotes.html)

I understand that llvm-gcc is being phased out in favour of dragonegg, but (at least according to its own website) dragonegg is still a bit rough around the edges and requires a patched gcc 4.5 to work. So llvm-gcc still serves an important role, if only for the Fortran and Ada compilers.

Albert

Hi Albert,

llvm-gcc is dead, deprecated in favour of clang and dragonegg. It won't be part
of the upcoming 3.0 release. This is why no-one is interested in working on it.

The tentative release notes still say otherwise: "LLVM 3.0 will be the
last release of llvm-gcc." (http://llvm.org/docs/ReleaseNotes.html)

this was a result of someone replacing 2.9 with 3.0 everywhere in that doc.
If you check the 2.9 release notes you will see that this was announced in
2.9 release.

I understand that llvm-gcc is being phased out in favour of dragonegg,
but (at least according to its own website) dragonegg is still a bit
rough around the edges and requires a patched gcc 4.5 to work.

The 3.0 version does not require a patched gcc-4.5. It also works with
gcc-4.6. It does have its rough spots, but they were all inherited from
llvm-gcc, which has the same problems and many more besides.

  So

llvm-gcc still serves an important role, if only for the Fortran and Ada
compilers.

In my opinion dragonegg now works better than llvm-gcc ever did, in particular
for Fortran.

Ciao, Duncan.

PS: A more convincing (IMO) argument against dragonegg is that it doesn't
work on windows. That's because the gcc plugin architecture doesn't work
on windows. Takumi has been thinking about this and has been enable to
get dragonegg to work on windows anyway using some clever tricks.

this was a result of someone replacing 2.9 with 3.0 everywhere in that doc.
If you check the 2.9 release notes you will see that this was announced in
2.9 release.

Ah, I should have thought of that. :slight_smile:

The 3.0 version does not require a patched gcc-4.5. It also works with
gcc-4.6. It does have its rough spots, but they were all inherited from
llvm-gcc, which has the same problems and many more besides.

Thanks, that's very good news! I'll give it another go then.

Albert

Hi Duncan,

PS: A more convincing (IMO) argument against dragonegg is that it doesn't
work on windows. That's because the gcc plugin architecture doesn't work
on windows. Takumi has been thinking about this and has been enable to
get dragonegg to work on windows anyway using some clever tricks.

Interesting, thanks for the information. Is that already available somewhere, or are there any plans to release it along with LLVM 3.0?

I don't use Windows much myself, but some Pure users and many of my students do. Pure relies on LLVM-capable compilers for its C/C++/Fortran inlining capabilities, so being able to just point Windows users to a binary llvm-gcc package to make that work is very convenient. Of course we can stick to the latest llvm-gcc 4.2 on Windows for a while, but if there's a dragonegg version that works there then I'd certainly like to give that a whirl some time.

Albert

Not yet. I have to do;

1) Submit my patches to upstream gcc.
2) Let patches applied by distributors (mingw, tdm, and cygwin)

X) Then, I could apply my tweaks :smiley:

GCC is required;

1) cc1*.exe should export (dllexport) available symbols.
2) People could use the distro "--enable-plugins and symbol-exported-cc1.exe"

With my experiments, dragonegg can run on cygwin.
Cygwin has its dlopen and dlsym.
For mingw, I have to implement their emulator. (It would not be hard)
Seek llvmdev with "dragonegg cygwin Takumi" :wink:

Unfortunately, I have little time to work on. Please be patient.

Thank you, ...Takumi

… but some Pure users and many of my students do. Pure relies on LLVM-capable compilers for its C/C++/Fortran
inlining capabilities, so being able to just point Windows users to a
binary llvm-gcc package to make that work is very convenient.

Nice to be called “Pure” :slight_smile: especially with capital letter.

MinGW binaries for llvm-gcc don’t have Fortran frontend.
That is why I needed to re-compile llvm-gcc at first place.

Thank you Takumi for your efforts.

たいへんよくできました ありがとうございました。

Interesting, thanks for the information. Is that already available
somewhere, or are there any plans to release it along with LLVM 3.0?

Not yet. I have to do;

1) Submit my patches to upstream gcc.
2) Let patches applied by distributors (mingw, tdm, and cygwin)

X) Then, I could apply my tweaks :smiley:

Takumi, thanks a lot for your work on this, I'm really looking forward to it! Having dragonegg work with cygwin/mingw would be a real boon.

Seek llvmdev with "dragonegg cygwin Takumi" :wink:

Ah yes, it seems that I've missed that post back then.

Unfortunately, I have little time to work on. Please be patient.

I understand that this involves a lot of work and getting these changes accepted upstream will surely take its time, too. For the time being, we'll just stick to LLVM 2.9 and llvm-gcc on Windows, no problem.

Thanks,
Albert

Nice to be called "Pure" :slight_smile: especially with capital letter.

Well, nowadays it's a major feat to find a short catchy name for a programming language which hasn't been taken yet.

MinGW binaries for llvm-gcc don't have Fortran frontend.
That is why I needed to re-compile llvm-gcc at first place.

Thanks for setting me straight on this. I was probably mistaken, but I seemed to recall that there was an llvm-gfortran in the Windows binaries of some older LLVM release. Anyway, once Takumi's cygwin/mingw dragonegg hatches, all these problems will be laid to rest. :slight_smile:

Cheers,
Albert

Tried it, works great! The only downside is that you need to go through LLVM assembler to generate bitcode, but that's not really a big issue.

Just FTR, Pure 0.48 (to be released today) now fully supports dragonegg for its C/C++/Fortran inlining, along with clang and llvm-gcc. It's also LLVM 3.0-ready, of course.

Duncan, thanks for your help,
Albert

Just a http://en.wikipedia.org/wiki/Small_matter_of_programming then :slight_smile:

Csaba