Flang compiled modules don't have a datalayout

I’m trying to use flang with LTO, and it almost works. The problem I stumbled over is that flang produces bitcode files without a datalayout. Then lld refuses to link them:

$ flang-new -L$LLVM_HOME/lib -fuse-ld=lld -flto=full hello.f90
ld.lld: error: /tmp/hello-59d521.o: input module has no datalayout

If I manually inject a datalayout, it works just fine (I borrowed that datalayout from a file produced by clang):

$ flang-new -c -flto=full hello.f90
$ flang-new -L$LLVM_HOME/lib -fuse-ld=lld -flto=full hello.o
ld.lld: error: hello.o: input module has no datalayout
flang-new: error: linker command failed with exit code 1 (use -v to see invocation)

$ opt --data-layout="e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128" hello.o -o hello-layout.o

$ flang-new -L$LLVM_HOME/lib -fuse-ld=lld -flto=full hello-layout.o
$ ./a.out
 Hello, World!

Not sure who’s at fault here. Is a datalayout mandatory? Clang always seems to produce one, so should flang do the same, too?

Or is this a problem with lld, that it should accept modules without a datalayout?

EDIT: In case it matters: This is with LLVM 15.0.6.

Could you try with the main branch?
@Leporacanthicus added the datalayout in ⚙ D133568 [Flang][Driver]Add datalayout before doing LLVM-IR transformation.

Whoops, my bad, I should have checked github issues, then I would have found this :wink:

Yes, this works on main (and also on release/16.x). Thanks!

Thanks @rschatz for confirming. There is a patch by @mnadeem that currently adds support for -flto flag (⚙ D142420 [Flang] Add support to use LTO specific pipelines). I am a bit surprised how you got it to work without this. Is that via local changes to add the -flto= flag?

Without the patch lto should still work but it would use a slightly different pass pipeline (for some reason flang accepted the -flto flag even before the patch).

Ah, ok. I guess for our use-case, I wouldn’t really notice the difference anyway. We’re actually passing --lto-O0, so not actually doing any optimizations at link-time. We’re really just interested in embedding the linked bitcode in the final ELF file, not so much in the actual link-time optimizations.

The other neat thing about LTO is that it sidesteps the missing support for -fPIC.

I believe -fPIC is supported in llvm/main (since some time back). Do you have a use-case where it doesn’t work? Or are you saying that we’re applying -fPIC “always”, and you want to to not be applied - or some other issue?

To be honest, we haven’t tried -fPIC with main. We started with LLVM 15.0.6, and there it didn’t work. We then updated to 16.0.0-RC1 for the above mentioned datalayout fix, but I we didn’t try without LTO again after the update.