• Marcel (13/13) May 06 2020 Hello!
• kinke (6/19) May 06 2020 This is a known bug of -enable-cross-module-inlining when
• kinke (3/4) May 06 2020 Or building each object file separately. [With parallelization,
• Marcel (17/21) May 07 2020 Thank you :)
• kinke (7/13) May 07 2020 Make sure to use -flto when linking too, not just when compiling
• Marcel (4/17) May 07 2020 I'm using VisualD on Windows 10. It seems that enabling LTO makes
• Marcel (3/3) May 07 2020 Oh, if I add -flto to the executable lld-link complains about
• kinke (3/6) May 07 2020 (Undocumented) /noopttls is then added by VisualD, as it's an old
• Marcel (2/9) May 07 2020 Fixed. Unfortunately the issue of the corrupt .lib still persists.
• kinke (11/13) May 07 2020 Have you tried to link in the shell directly, without VisualD? If
• kinke (9/11) May 07 2020 I've just tried another potential source of error, which occurs
• Marcel (2/13) May 07 2020 That's a shame, I'll try using dub later.
• Rainer Schuetze (2/15) May 08 2020 Please file a bug report at issues.dlang.org for compoonent visuald.
• Marcel (2/19) May 08 2020 Done :)

Marcel <marcelpi97 gmail.com> writes:

Hello!
I have a simple wrapper type around LLVM's atomic intrinsics in a 
static library, which I use in a separate, also static, library. 
Today I noticed that even though all of the type's methods are 
explicitly marked as forceinline, that their body consists of a 
single instruction and that I'm using 
"-enable-cross-module-inlining=true", all method calls are NOT 
inlined.
This happens regardless of whether I'm using 
llvmAttr("alwaysinline"), pragma(inline, true) or even if I 
remove all inlining annotations.
Am I missing something or is this a compiler bug? Does anyone 
know of any workaround?

kinke <noone nowhere.com> writes:

On Wednesday, 6 May 2020 at 20:16:19 UTC, Marcel wrote:
 Hello!
 I have a simple wrapper type around LLVM's atomic intrinsics in 
 a static library, which I use in a separate, also static, 
 library. Today I noticed that even though all of the type's 
 methods are explicitly marked as forceinline, that their body 
 consists of a single instruction and that I'm using 
 "-enable-cross-module-inlining=true", all method calls are NOT 
 inlined.
 This happens regardless of whether I'm using 
 llvmAttr("alwaysinline"), pragma(inline, true) or even if I 
 remove all inlining annotations.
 Am I missing something or is this a compiler bug? Does anyone 
 know of any workaround?

This is a known bug of -enable-cross-module-inlining when 
compiling several object files in a single cmdline (the default 
when building a static library) - a function can only be emitted 
into a single object file.

The workaround is using LTO.

kinke <noone nowhere.com> writes:

On Thursday, 7 May 2020 at 01:51:22 UTC, kinke wrote:
 The workaround is using LTO.

Or building each object file separately. [With parallelization, 
this might be faster than all-at-once compilation.]

Marcel <marcelpi97 gmail.com> writes:

On Thursday, 7 May 2020 at 01:56:42 UTC, kinke wrote:
 On Thursday, 7 May 2020 at 01:51:22 UTC, kinke wrote:
 The workaround is using LTO.

 Or building each object file separately. [With parallelization, 
 this might be faster than all-at-once compilation.]

Thank you :)
I have another problem though, when using -flto (full or thin) I 
get weird error messages when linking the library with the final 
executable:

C:\foo\bin\release\x64\foo.lib : fatal error LNK1107: invalid or 
corrupt file: cannot read at 0x1C4C8

The command line parameters I'm using:

-mattr=sse,sse2
-preview=intpromote
-inline-threshold=256
-inlinehint-threshold=512
-enable-cross-module-inlining=true
-flto=full
-linker=gold
-nogc

What am I missing?

kinke <noone nowhere.com> writes:

On Thursday, 7 May 2020 at 09:57:24 UTC, Marcel wrote:
 I have another problem though, when using -flto (full or thin) 
 I get weird error messages when linking the library with the 
 final executable

Make sure to use -flto when linking too, not just when compiling 
the lib(s). LDC defaults to the bundled lld-link.exe on Windows 
then, which does support LTO libs.

 -mattr=sse,sse2

Implicit for x86_64 targets.

 -enable-cross-module-inlining=true

Doesn't make much sense with LTO.

 -linker=gold

On Windows?

Marcel <marcelpi97 gmail.com> writes:

On Thursday, 7 May 2020 at 13:45:14 UTC, kinke wrote:
 On Thursday, 7 May 2020 at 09:57:24 UTC, Marcel wrote:
 I have another problem though, when using -flto (full or thin) 
 I get weird error messages when linking the library with the 
 final executable

 Make sure to use -flto when linking too, not just when 
 compiling the lib(s). LDC defaults to the bundled lld-link.exe 
 on Windows then, which does support LTO libs.

 -mattr=sse,sse2

 Implicit for x86_64 targets.

 -enable-cross-module-inlining=true

 Doesn't make much sense with LTO.

 -linker=gold

 On Windows?

I'm using VisualD on Windows 10. It seems that enabling LTO makes 
the linker lld-link (forget about -linker=gold) complain about 
/noopttls.

Marcel <marcelpi97 gmail.com> writes:

Oh, if I add -flto to the executable lld-link complains about 
noopttls and if I remove it I get LNK1107 (invalid or corrupt 
file).

kinke <noone nowhere.com> writes:

On Thursday, 7 May 2020 at 17:21:13 UTC, Marcel wrote:
 I'm using VisualD on Windows 10. It seems that enabling LTO 
 makes the linker lld-link (forget about -linker=gold) complain 
 about /noopttls.

(Undocumented) /noopttls is then added by VisualD, as it's an old 
workaround for druntime < 2.076 + VS 2017+ and not needed anymore.

Marcel <marcelpi97 gmail.com> writes:

On Thursday, 7 May 2020 at 17:40:29 UTC, kinke wrote:
 On Thursday, 7 May 2020 at 17:21:13 UTC, Marcel wrote:
 I'm using VisualD on Windows 10. It seems that enabling LTO 
 makes the linker lld-link (forget about -linker=gold) complain 
 about /noopttls.

 (Undocumented) /noopttls is then added by VisualD, as it's an 
 old workaround for druntime < 2.076 + VS 2017+ and not needed 
 anymore.

Fixed. Unfortunately the issue of the corrupt .lib still persists.

kinke <noone nowhere.com> writes:

On Thursday, 7 May 2020 at 22:14:16 UTC, Marcel wrote:
 Fixed. Unfortunately the issue of the corrupt .lib still 
 persists.

Have you tried to link in the shell directly, without VisualD? If 
you get that LNK error, that's from the MS linker, which of 
course doesn't have the faintest idea about LLVM bitcode. So 
lld-link.exe is required (and as said, the default linker in such 
a scenario unless another build tool interferes).

Note that the ldc2 binaries in the official LDC packages are 
built with LTO (across C++ and D, incl. druntime from D host 
compiler), so it's not like LTO would be completely untested and 
totally unbuggy, as the reports here in the forum might suggest 
(as always, the majority for which it's working is silent).

kinke <noone nowhere.com> writes:

On Thursday, 7 May 2020 at 22:14:16 UTC, Marcel wrote:
 Fixed. Unfortunately the issue of the corrupt .lib still 
 persists.

I've just tried another potential source of error, which occurs 
when generating (not linking) the static LTO library. That 
requires generating the static lib with LDC (`-lib`), as it uses 
LLVM's librarian/archiver with bitcode support. When using MS 
lib.exe, I get that LNK1107 error you've mentioned (with an 
object file prefix in the error msg though, unlike your example). 
So VisualD might use the MS librarian unconditionally in your 
case...

Marcel <marcelpi97 gmail.com> writes:

On Thursday, 7 May 2020 at 23:05:30 UTC, kinke wrote:
 On Thursday, 7 May 2020 at 22:14:16 UTC, Marcel wrote:
 Fixed. Unfortunately the issue of the corrupt .lib still 
 persists.

 I've just tried another potential source of error, which occurs 
 when generating (not linking) the static LTO library. That 
 requires generating the static lib with LDC (`-lib`), as it 
 uses LLVM's librarian/archiver with bitcode support. When using 
 MS lib.exe, I get that LNK1107 error you've mentioned (with an 
 object file prefix in the error msg though, unlike your 
 example). So VisualD might use the MS librarian unconditionally 
 in your case...

That's a shame, I'll try using dub later.

Rainer Schuetze <r.sagitario gmx.de> writes:

On 08/05/2020 01:28, Marcel wrote:
 On Thursday, 7 May 2020 at 23:05:30 UTC, kinke wrote:
 On Thursday, 7 May 2020 at 22:14:16 UTC, Marcel wrote:
 Fixed. Unfortunately the issue of the corrupt .lib still persists.

 I've just tried another potential source of error, which occurs when
 generating (not linking) the static LTO library. That requires
 generating the static lib with LDC (`-lib`), as it uses LLVM's
 librarian/archiver with bitcode support. When using MS lib.exe, I get
 that LNK1107 error you've mentioned (with an object file prefix in the
 error msg though, unlike your example). So VisualD might use the MS
 librarian unconditionally in your case...

 
 That's a shame, I'll try using dub later.

Please file a bug report at issues.dlang.org for compoonent visuald.

Marcel <marcelpi97 gmail.com> writes:

On Friday, 8 May 2020 at 07:04:28 UTC, Rainer Schuetze wrote:
 On 08/05/2020 01:28, Marcel wrote:
 On Thursday, 7 May 2020 at 23:05:30 UTC, kinke wrote:
 On Thursday, 7 May 2020 at 22:14:16 UTC, Marcel wrote:
 [...]

 I've just tried another potential source of error, which 
 occurs when generating (not linking) the static LTO library. 
 That requires generating the static lib with LDC (`-lib`), as 
 it uses LLVM's librarian/archiver with bitcode support. When 
 using MS lib.exe, I get that LNK1107 error you've mentioned 
 (with an object file prefix in the error msg though, unlike 
 your example). So VisualD might use the MS librarian 
 unconditionally in your case...

 
 That's a shame, I'll try using dub later.

 Please file a bug report at issues.dlang.org for compoonent 
 visuald.

Done :)