[Issue 24686] SumType stopped working on LDC 1.37 with unmatched DeducedParameterType template
https://issues.dlang.org/show_bug.cgi?id=24686 Luís Ferreira changed: What|Removed |Added Hardware|x86 |All OS|Windows |All Severity|enhancement |regression --
[Issue 24686] New: SumType stopped working on LDC 1.37 with unmatched DeducedParameterType template
https://issues.dlang.org/show_bug.cgi?id=24686 Issue ID: 24686 Summary: SumType stopped working on LDC 1.37 with unmatched DeducedParameterType template Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: cont...@lsferreira.net Compiling an argument parser (cant really deduce the code snippet) 63874b2ce32b165436d3007515377ef5d5dce22d version of https://github.com/andrey-zherikov/argparse yields the following error on LDC 1.37 and beyond. ``` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(Unknown))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(Argument))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(SubCommand))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(Unknown))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(Argument))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(SubCommand))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(Unknown))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(Argument))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(SubCommand))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(Unknown))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(Argument))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(SubCommand))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(Unknown))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(Argument))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(SubCommand))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(Unknown))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(Argument))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(SubCommand))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(Unknown))` does not match template declaration `DeducedParameterType(T)` /home/luis/.local/bin/../import/std/sumtype.d(418): Error: template instance `DeducedParameterType!(inout(Argument))` does not match template declaration `DeducedParameterType(T)` ``` Turns out `DeducedParameterType` doesn't accept aliased types. Ultimately this should be a compiler issue, in my understanding of the language spec, as T and alias T shouldn't differ for types, but somehow it does. Making `DeducedParameterType` accepting aliased types, works. --
Re: LDC 1.39.0
On Thu, Jul 04, 2024 at 11:28:56AM +, kinke via Digitalmars-d-announce wrote: > Glad to announce LDC 1.39.0. Major changes: > > * Based on D 2.109.1. > * LLVM for prebuilt packages bumped to v18.1.6. > * musl libc: Misc. bug fixes and removal of libunwind dependency. > * Support for LLVM 11-14 was dropped. The CLI options `-passmanager` and > `-opaque-pointers` were removed. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.39.0 [...] Big thank you to the LDC team for continuing to bring us this awesome compiler! T -- "640K ought to be enough" -- Bill G. (allegedly), 1984. "The Internet is not a primary goal for PC usage" -- Bill G., 1995. "Linux has no impact on Microsoft's strategy" -- Bill G., 1999.
Re: LDC 1.39.0
On Friday, 5 July 2024 at 00:27:21 UTC, Steven Schveighoffer wrote: On Thursday, 4 July 2024 at 11:28:56 UTC, kinke wrote: Glad to announce LDC 1.39.0. Major changes: * Based on D 2.109.1. * LLVM for prebuilt packages bumped to v18.1.6. * musl libc: Misc. bug fixes and removal of libunwind dependency. * Support for LLVM 11-14 was dropped. The CLI options `-passmanager` and `-opaque-pointers` were removed. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.39.0 Thanks to all contributors & sponsors! FYI, I want to mention that I truly appreciate how timely LDC is released in the wake of DMD updates! You do a great job, Martin! Especially for those of us who are exclusively on ARM platforms (a lot more now that it's the main arch that Apple uses). -Steve I imagined you'd be on Intel Mac.
Re: LDC 1.39.0
On Thursday, 4 July 2024 at 11:28:56 UTC, kinke wrote: Glad to announce LDC 1.39.0. Major changes: * Based on D 2.109.1. * LLVM for prebuilt packages bumped to v18.1.6. * musl libc: Misc. bug fixes and removal of libunwind dependency. * Support for LLVM 11-14 was dropped. The CLI options `-passmanager` and `-opaque-pointers` were removed. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.39.0 Thanks to all contributors & sponsors! FYI, I want to mention that I truly appreciate how timely LDC is released in the wake of DMD updates! You do a great job, Martin! Especially for those of us who are exclusively on ARM platforms (a lot more now that it's the main arch that Apple uses). -Steve
LDC 1.39.0
Glad to announce LDC 1.39.0. Major changes: * Based on D 2.109.1. * LLVM for prebuilt packages bumped to v18.1.6. * musl libc: Misc. bug fixes and removal of libunwind dependency. * Support for LLVM 11-14 was dropped. The CLI options `-passmanager` and `-opaque-pointers` were removed. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.39.0 Thanks to all contributors & sponsors!
Re: LDC 1.39.0-beta1
On Monday, 3 June 2024 at 19:42:42 UTC, kinke wrote: Glad to announce the first beta for LDC 1.39. Major changes: * Based on D 2.109.0. * LLVM for prebuilt packages bumped to v18.1.6. * Support for LLVM 11-14 was dropped. The CLI options `-passmanager` and `-opaque-pointers` were removed. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.39.0-beta1 Please help test, and thanks to all contributors & sponsors! 1.38.0 work fine with `-mtriple=x86_64-w64-mingw32 -march=x86-64` from linux. v1.39.0-beta1 throw this error: ```sh call void @__assert_fail(ptr @.str, ptr @.str.8, i32 8860, ptr @.str.24) #2, !dbg !515 Incorrect number of arguments passed to called function! call void @__assert_fail(ptr @.str.23, ptr @.str.8, i32 8858, ptr @.str.24) #2, !dbg !512 LLVM ERROR: Broken module found, compilation aborted! #0 0x55b9b789c697 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/local/ldc2/bin/ldc2+0x6dcb697) #1 0x55b9b789a48c llvm::sys::RunSignalHandlers() (/usr/local/ldc2/bin/ldc2+0x6dc948c) #2 0x55b9b789cd3f SignalHandler(int) Signals.cpp:0:0 #3 0x7f2a09446050 (/lib/x86_64-linux-gnu/libc.so.6+0x3c050) #4 0x7f2a09494e2c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76 #5 0x7f2a09445fb2 raise ./signal/../sysdeps/posix/raise.c:27:6 #6 0x7f2a09430472 abort ./stdlib/abort.c:81:7 #7 0x55b9b7805372 llvm::report_fatal_error(llvm::Twine const&, bool) (/usr/local/ldc2/bin/ldc2+0x6d34372) #8 0x55b9b78051a6 (/usr/local/ldc2/bin/ldc2+0x6d341a6) #9 0x55b9b76945ac (/usr/local/ldc2/bin/ldc2+0x6bc35ac) #10 0x55b9b7b7841d llvm::detail::PassModelllvm::VerifierPass, llvm::PreservedAnalyses, llvm::AnalysisManager>::run(llvm::Module&, llvm::AnalysisManager&) ld-temp.o:0:0 #11 0x55b9b766b214 llvm::PassManagerllvm::AnalysisManager>::run(llvm::Module&, llvm::AnalysisManager&) (/usr/local/ldc2/bin/ldc2+0x6b9a214) #12 0x55b9b7b72696 runOptimizationPasses(llvm::Module*) (/usr/local/ldc2/bin/ldc2+0x70a1696) #13 0x55b9b7c0200e writeModule(llvm::Module*, char const*) (/usr/local/ldc2/bin/ldc2+0x713100e) #14 0x55b9b7c010da ldc::CodeGenerator::writeAndFreeLLModule(char const*) (/usr/local/ldc2/bin/ldc2+0x71300da) #15 0x55b9b7c01b47 ldc::CodeGenerator::emit(Module*) (/usr/local/ldc2/bin/ldc2+0x7130b47) #16 0x55b9b4640238 codegenModules(Array&) (/usr/local/ldc2/bin/ldc2+0x3b6f238) #17 0x55b9b45deae1 mars_tryMain(Param&, Array&) (/usr/local/ldc2/bin/ldc2+0x3b0dae1) #18 0x55b9b4643de0 cppmain() (/usr/local/ldc2/bin/ldc2+0x3b72de0) #19 0x55b9b7dbc63d _D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZv (/usr/local/ldc2/bin/ldc2+0x72eb63d) #20 0x55b9b7dbc418 _d_run_main2 (/usr/local/ldc2/bin/ldc2+0x72eb418) #21 0x55b9b7dbc22d _d_run_main (/usr/local/ldc2/bin/ldc2+0x72eb22d) #22 0x55b9b7bfe6e8 main (/usr/local/ldc2/bin/ldc2+0x712d6e8) #23 0x7f2a0943124a __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3 #24 0x7f2a09431305 call_init ./csu/../csu/libc-start.c:128:20 #25 0x7f2a09431305 __libc_start_main ./csu/../csu/libc-start.c:347:5 #26 0x55b9b4647d5e _start (/usr/local/ldc2/bin/ldc2+0x3b76d5e) Error: Error executing /usr/local/ldc2/bin/ldc2: Aborted ```
LDC 1.39.0-beta1
Glad to announce the first beta for LDC 1.39. Major changes: * Based on D 2.109.0. * LLVM for prebuilt packages bumped to v18.1.6. * Support for LLVM 11-14 was dropped. The CLI options `-passmanager` and `-opaque-pointers` were removed. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.39.0-beta1 Please help test, and thanks to all contributors & sponsors!
Re: LDC 1.38.0
On 5/10/2024 6:22 PM, kinke wrote: Glad to announce LDC 1.38.0. Major changes: - Based on D 2.108.1. - Support for LLVM 18; the prebuilt packages use v18.1.5. - Android: Switch to native ELF TLS, supported since API level 29 (Android v10), dropping our former custom TLS emulation (requiring a modified LLVM and a legacy ld.bfd linker). The prebuilt packages themselves require Android v10+ (armv7a) / v11+ (aarch64) too, and are built with NDK r26d. Shared druntime and Phobos libraries are now available (`-link-defaultlib-shared`), as on regular Linux. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.38.0 Thanks to all contributors & sponsors! Great work!
Re: LDC 1.38.0
On Sat, May 11, 2024 at 01:22:58AM +, kinke via Digitalmars-d-announce wrote: > Glad to announce LDC 1.38.0. Major changes: > > - Based on D 2.108.1. > - Support for LLVM 18; the prebuilt packages use v18.1.5. > - Android: Switch to native ELF TLS, supported since API level 29 (Android > v10), dropping our former custom TLS emulation (requiring a modified LLVM > and a legacy ld.bfd linker). The prebuilt packages themselves require > Android v10+ (armv7a) / v11+ (aarch64) too, and are built with NDK r26d. > Shared druntime and Phobos libraries are now available > (`-link-defaultlib-shared`), as on regular Linux. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.38.0 > > Thanks to all contributors & sponsors! Thanks for continuing to bring us this awesome compiler! --T
Re: LDC 1.38.0
On Saturday, 11 May 2024 at 01:22:58 UTC, kinke wrote: Glad to announce LDC 1.38.0. Major changes: - Based on D 2.108.1. - Support for LLVM 18; the prebuilt packages use v18.1.5. - Android: Switch to native ELF TLS, supported since API level 29 (Android v10), dropping our former custom TLS emulation (requiring a modified LLVM and a legacy ld.bfd linker). The prebuilt packages themselves require Android v10+ (armv7a) / v11+ (aarch64) too, and are built with NDK r26d. Shared druntime and Phobos libraries are now available (`-link-defaultlib-shared`), as on regular Linux. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.38.0 Thanks to all contributors & sponsors! Thanks a lot Martin! I'm super excited to integrate the new NDK support to my engine tool so it can still automatically integrate with the most up to date version :)
LDC 1.38.0
Glad to announce LDC 1.38.0. Major changes: - Based on D 2.108.1. - Support for LLVM 18; the prebuilt packages use v18.1.5. - Android: Switch to native ELF TLS, supported since API level 29 (Android v10), dropping our former custom TLS emulation (requiring a modified LLVM and a legacy ld.bfd linker). The prebuilt packages themselves require Android v10+ (armv7a) / v11+ (aarch64) too, and are built with NDK r26d. Shared druntime and Phobos libraries are now available (`-link-defaultlib-shared`), as on regular Linux. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.38.0 Thanks to all contributors & sponsors!
[Issue 24526] New: Upstream ldc optStrategy to disable optimizations in a function
https://issues.dlang.org/show_bug.cgi?id=24526
Issue ID: 24526
Summary: Upstream ldc optStrategy to disable optimizations in a
function
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: alphaglosi...@gmail.com
Being able to disable optimizations guarantees that the backend will not
subvert something that you explicitly wanted.
``@optStrategy("none")``
>From core.attributes.
This is useful for constant time equality for crypto libraries.
A request from Adam Wilson.
--
[Issue 24526] Upstream ldc optStrategy to disable optimizations in a function
https://issues.dlang.org/show_bug.cgi?id=24526 Richard Cattermole changed: What|Removed |Added Keywords||industry Priority|P1 |P2 --
Re: LDC 1.38.0-beta1
On 20/04/2024 12:41 PM, kinke wrote: Android: Switch to native ELF TLS, supported since API level 29 (Android v10), dropping our former custom TLS emulation (requiring a modified LLVM and a legacy ld.bfd linker). The prebuilt packages themselves require Android v10+ (armv7a) / v11+ (aarch64) too, and are built with NDK r26d. Shared druntime and Phobos libraries are now available (|-link-defaultlib-shared|), as on regular Linux. I shared that on Discord. This is something I've been looking forward to for a long time! Thanks Today has sure been a good day.
LDC 1.38.0-beta1
Glad to announce the first beta for LDC 1.38. Major changes: * Based on D 2.108.0+ (yesterday's DMD stable). * Support for LLVM 18; the prebuilt packages use v18.1.3. * Android: Switch to native ELF TLS, supported since API level 29 (Android v10), dropping our former custom TLS emulation (requiring a modified LLVM and a legacy ld.bfd linker). The prebuilt packages themselves require Android v10+ (armv7a) / v11+ (aarch64) too, and are built with NDK r26d. Shared druntime and Phobos libraries are now available (`-link-defaultlib-shared`), as on regular Linux. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.38.0-beta1 Please help test, and thanks to all contributors & sponsors!
Re: LDC Internal Compiler Error (ICE) mentioning attribute 'nocapture'
On Saturday, 30 March 2024 at 09:35:24 UTC, Per Nordlöw wrote:
Does anybody recognize the error
```
Attribute 'nocapture' does not apply to function return values
%12 = call noalias nocapture align 8 ptr @_D3xxx(ptr nonnull
%10, { i64, ptr } %11) #2, !dbg !7978
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz1
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz2
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz3
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz4
Attribute 'nocapture' does not apply to function return values
%164 = call noalias nocapture align 8 ptr @_D3xyz5(ptr
nonnull %rS72) #0, !dbg !9872
Attribute 'nocapture' does not apply to function return values
%285 = call noalias nocapture align 8 ptr @_D3xyz6(ptr
nonnull %284) #0, !dbg !9949
LLVM ERROR: Broken module found, compilation aborted!
#0 0x5ee4d001e927
llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(~/.local/ldc2-1.37.0-beta1-linux-x86_64/bin/ldc2+0x6ad4927)
Error ldc2 failed with exit code -6.
```
? It's outputted when building and running a test application
with ldc with the compiler flag `-fsanitize=address`.
You can try to add the flag `--disable-verify` (see
https://github.com/ldc-developers/ldc/issues/4284, that prevents
an internal verification).
The error message indicates that a "parameter-only" attribute is
used as a "call-site" one. Not sure if this is a bug in LDC or in
LLVM but if you're lucky the attribute will be a no-op and the
generated binary will just work.
LDC Internal Compiler Error (ICE) mentioning attribute 'nocapture'
Does anybody recognize the error
```
Attribute 'nocapture' does not apply to function return values
%12 = call noalias nocapture align 8 ptr @_D3xxx(ptr nonnull
%10, { i64, ptr } %11) #2, !dbg !7978
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz1
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz2
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz3
Attribute 'nocapture' does not apply to function return values
ptr @_D3xyz4
Attribute 'nocapture' does not apply to function return values
%164 = call noalias nocapture align 8 ptr @_D3xyz5(ptr nonnull
%rS72) #0, !dbg !9872
Attribute 'nocapture' does not apply to function return values
%285 = call noalias nocapture align 8 ptr @_D3xyz6(ptr nonnull
%284) #0, !dbg !9949
LLVM ERROR: Broken module found, compilation aborted!
#0 0x5ee4d001e927
llvm::sys::PrintStackTrace(llvm::raw_ostream&, int)
(~/.local/ldc2-1.37.0-beta1-linux-x86_64/bin/ldc2+0x6ad4927)
Error ldc2 failed with exit code -6.
```
? It's outputted when building and running a test application
with ldc with the compiler flag `-fsanitize=address`.
Re: LDC 1.37.0
On Sunday, 3 March 2024 at 14:46:34 UTC, kinke wrote: Glad to announce LDC 1.37.0. Major changes: * Based on D 2.107.1. * Important fix wrt. if-statement elision on constant condition. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.37.0 Thanks to all contributors & sponsors! Thanks for update. https://github.com/llvm/llvm-project/releases/tag/llvmorg-18.1.0 released
Re: LDC 1.37.0
On Sun, Mar 03, 2024 at 02:46:34PM +, kinke via Digitalmars-d-announce wrote: > Glad to announce LDC 1.37.0. Major changes: > > * Based on D 2.107.1. > * Important fix wrt. if-statement elision on constant condition. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.37.0 > > Thanks to all contributors & sponsors! Awesome, thanks to the LDC team for another fine compiler! --T
Re: LDC 1.37.0
On Sunday, 3 March 2024 at 14:46:34 UTC, kinke wrote: Glad to announce LDC 1.37.0. Major changes: * Based on D 2.107.1. * Important fix wrt. if-statement elision on constant condition. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.37.0 Thanks to all contributors & sponsors! Thanks a lot, that was also quite the quick catch-up from dmd!
Re: LDC 1.37.0
On Sunday, 3 March 2024 at 14:46:34 UTC, kinke wrote: Glad to announce LDC 1.37.0. Major changes: * Based on D 2.107.1. * Important fix wrt. if-statement elision on constant condition. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.37.0 Thanks to all contributors & sponsors! Thank you for the hard work!
LDC 1.37.0
Glad to announce LDC 1.37.0. Major changes: * Based on D 2.107.1. * Important fix wrt. if-statement elision on constant condition. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.37.0 Thanks to all contributors & sponsors!
Re: LDC Stacktrace with symbols instead of addresses
On Monday, 12 February 2024 at 16:14:27 UTC, Per Nordlöw wrote: . Doing the same thing with LDC via ```sh ldc2 -g --d-debug -run app ``` gives ``` ld: error: undefined symbol: _D3etc5linux11memoryerror26registerMemoryErrorHandlerFNbZb referenced by app.d:3 /tmp/objtmp-ldc-dec7a7/app.o:(D main) collect2: error: ld returned 1 exit status Error: /usr/bin/cc failed with status: 1 ``` LDC does not support etc.linux.memoryerror, due to issues with it. See: https://github.com/ldc-developers/ldc/issues/1915 -Johan
Re: LDC Stacktrace with symbols instead of addresses
I agree, debug builds should show proper stack trace by default You should submit a PR for dmd and call what ever is that function behind a `debug` block when it hooks the C main function As for LDC, it's weird that it doesn't work, they should share the same runtime no?
Re: LDC Stacktrace with symbols instead of addresses
On Sunday, 11 February 2024 at 06:43:19 UTC, Per Nordlöw wrote:
How do I make LDC stacktraces like
```test-library(+0x1fb232)[0x562230d82232]
So it turns out that ldc2 doesn't show symbols in stack traces by
default.
IMHO, in debug mode D should adhere to what other languages do.
Meaning a sane behavior like what
```d
int main(string[] args) {
import etc.linux.memoryerror : registerMemoryErrorHandler;
registerMemoryErrorHandler();
int*x = null;
*x = 42;
return 0;
}
```
does when using compiled and run via
```sh
dmd -g -debug -run app
```
gives
```
etc.linux.memoryerror.NullPointerError@src/etc/linux/memoryerror.d(322)
??:? void etc.linux.memoryerror.sigsegvUserspaceProcess(void*)
[0x55fd3461e4f6]
??:? void etc.linux.memoryerror.sigsegvDataHandler()
[0x55fd3461e42e]
./app.d:4 _Dmain [0x55fd345e53e6]
```
. Doing the same thing with LDC via
```sh
ldc2 -g --d-debug -run app
```
gives
```
ld: error: undefined symbol:
_D3etc5linux11memoryerror26registerMemoryErrorHandlerFNbZb
referenced by app.d:3
/tmp/objtmp-ldc-dec7a7/app.o:(D main)
collect2: error: ld returned 1 exit status
Error: /usr/bin/cc failed with status: 1
```
.
LDC Stacktrace with symbols instead of addresses
How do I make LDC stacktraces like ```test-library(+0x1fb232)[0x562230d82232] test-library(+0x2a35b7)[0x562230e2a5b7] /lib/x86_64-linux-gnu/libc.so.6(+0x42520)[0x7f6ad2242520] test-library(+0x7521a)[0x562230bfc21a] test-library(+0x79083)[0x562230c00083] test-library(+0x2a35f5)[0x562230e2a5f5] test-library(+0x2b0627)[0x562230e37627] test-library(+0x2b0b59)[0x562230e37b59] test-library(+0x2b05cc)[0x562230e375cc] test-library(+0x2a7b9f)[0x562230e2eb9f] test-library(+0x2a34a4)[0x562230e2a4a4] test-library(+0x2aac5b)[0x562230e31c5b] test-library(+0x2aab87)[0x562230e31b87] test-library(+0x2aa9dd)[0x562230e319dd] test-library(+0xa71d2)[0x562230c2e1d2] /lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x7f6ad2229d90] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x7f6ad2229e40] test-library(+0x4db45)[0x562230bd4b45] Error Program exited with code -11``` show symbols instead of adresses? I am compiling with `-g --d-debug -fsanitize=address`.
LDC 1.37.0-beta1
Glad to announce the first beta for LDC 1.37. The single major change for now is the bump to D v2.107.0+. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.37.0-beta1 Please help test, and thanks to all contributors & sponsors!
Re: A Conversation with Martin Kinkelin on LDC
Martin is indeed a treasure!
Re: A Conversation with Martin Kinkelin on LDC
On Sunday, 28 January 2024 at 18:11:24 UTC, Mike Parker wrote: Some of you may recall the two conversations I had with Walter a while back, part of what I called the 'D Community Conversations' series. I've long planned to get that going as a regular, monthly thing. Finally, the time has come. I want to thank Martin Kinkelin for agreeing to sit down with me to chat about his road to programming and to the D language, how he ended up as the lead maintainer of LDC, and some of the details about the role. [snip] Thanks to Martin for his hard work on LDC!
Re: A Conversation with Martin Kinkelin on LDC
On Sunday, 28 January 2024 at 18:11:24 UTC, Mike Parker wrote: Some of you may recall the two conversations I had with Walter a while back, part of what I called the 'D Community Conversations' series. I've long planned to get that going as a regular, monthly thing. Finally, the time has come. I want to thank Martin Kinkelin for agreeing to sit down with me to chat about his road to programming and to the D language, how he ended up as the lead maintainer of LDC, and some of the details about the role. I very much enjoyed our conversation. I hope you do, too. You can find it here: https://youtu.be/XpPV5OBJEvg The full playlist is here: https://youtube.com/playlist?list=PLIldXzSkPUXXEL-2gfragUgNC2P2Yw6au=jih87SW_4A7jwRt5 Look for the next episode on the last weekend in February. LDC is one of the most, if not THE most important project for D, it produces very fast and competitive executables, not only that but makes it possible to target all kind of platforms, including WebAssembly! Other languages dream of having this DMD + LDC combo, very fast iteration time with debug builds thanks to DMD and very fast production code thanks to LDC! It's super interesting to be able to listen to Martin's story, i keep hear about how LLVM is painful to work with, mostly during version upgrades.. I admire you, thanks!
Re: A Conversation with Martin Kinkelin on LDC
On Sunday, 28 January 2024 at 19:12:39 UTC, Johan wrote: Hey Mike and Martin, It's very nice that you took the time to have this conversation and record it! Great to be able to put a face to an internet name, and hear a little about someones back story :) I'm happy you touched on Martin's CI work besides his programming contributions, because CI/packaging is probably not something many people think about when you say "compiler development". The (continued) work on CI and automatic release packaging by Martin has been enormous. It has taken a huge amount of time and effort - and I'm sure a lot of frustration went along with it - but the end result really is stellar. As Martin mentions, it works for forks as well, great stuff. cheers, Johan And it is a work that makes a complete difference. Trying always to "Build It Yourself" is always a huge pain. There's too much setup to be done, and as a cross platform developer, I can see how much work it is going there. At least my latest 200 commits has been on smooth UX across the platforms for cross compiling. One can just wonder how much work it goes to that when you're a step lower on compiler development.
Re: A Conversation with Martin Kinkelin on LDC
On Sunday, 28 January 2024 at 18:11:24 UTC, Mike Parker wrote: Some of you may recall the two conversations I had with Walter a while back, part of what I called the 'D Community Conversations' series. I've long planned to get that going as a regular, monthly thing. Finally, the time has come. I want to thank Martin Kinkelin for agreeing to sit down with me to chat about his road to programming and to the D language, how he ended up as the lead maintainer of LDC, and some of the details about the role. Hey Mike and Martin, It's very nice that you took the time to have this conversation and record it! Great to be able to put a face to an internet name, and hear a little about someones back story :) I'm happy you touched on Martin's CI work besides his programming contributions, because CI/packaging is probably not something many people think about when you say "compiler development". The (continued) work on CI and automatic release packaging by Martin has been enormous. It has taken a huge amount of time and effort - and I'm sure a lot of frustration went along with it - but the end result really is stellar. As Martin mentions, it works for forks as well, great stuff. cheers, Johan
A Conversation with Martin Kinkelin on LDC
Some of you may recall the two conversations I had with Walter a while back, part of what I called the 'D Community Conversations' series. I've long planned to get that going as a regular, monthly thing. Finally, the time has come. I want to thank Martin Kinkelin for agreeing to sit down with me to chat about his road to programming and to the D language, how he ended up as the lead maintainer of LDC, and some of the details about the role. I very much enjoyed our conversation. I hope you do, too. You can find it here: https://youtu.be/XpPV5OBJEvg The full playlist is here: https://youtube.com/playlist?list=PLIldXzSkPUXXEL-2gfragUgNC2P2Yw6au=jih87SW_4A7jwRt5 Look for the next episode on the last weekend in February.
Re: Using C++ Classes From D: dmd cannot link, while ldc segfault
On Friday, 26 January 2024 at 14:46:08 UTC, Emmanuel Danso Nyarko wrote: Yes, this is a project currently in progress. Vector was only working for windows but we have it working on linux but it's not yet ready to be used that's why you could only use it from a standalone fork. [here](https://forum.dlang.org/post/vmdisnkuffjgbxbyu...@forum.dlang.org) vector is not stable.
Re: Using C++ Classes From D: dmd cannot link, while ldc segfault
On Friday, 26 January 2024 at 13:40:12 UTC, Matheus Catarino wrote: On Friday, 26 January 2024 at 09:06:16 UTC, Emmanuel Danso Nyarko wrote: On Thursday, 25 January 2024 at 21:41:36 UTC, Matheus Catarino wrote: https://forum.dlang.org/post/kawfhminmtmwbmkzh...@forum.dlang.org On Monday, 19 June 2023 at 06:11:59 UTC, mw wrote: LDC - the LLVM D compiler (1.32.2): ``` main.d(32): Error: undefined identifier `vector` in module `core.stdcpp.vector`, did you mean enum member `MIctor`? ``` So what's wrong the LDC? how do I write `core.stdcpp.vector.vector` then? Currently, I was only able to get rid of this error using a fork of stdcpp still in progress in the standalone repository. Ref.: https://github.com/dlang/stdcpp/issues/5 What OS are you using? It's mentioned in the reference link. OS: ArchLinux Yes, this is a project currently in progress. Vector was only working for windows but we have it working on linux but it's not yet ready to be used that's why you could only use it from a standalone fork. We will be getting everything from the fork to the main tree soon after it is complete. We will notify the community when it's ready to be used. Thanks!
Re: Using C++ Classes From D: dmd cannot link, while ldc segfault
On Friday, 26 January 2024 at 09:06:16 UTC, Emmanuel Danso Nyarko wrote: On Thursday, 25 January 2024 at 21:41:36 UTC, Matheus Catarino wrote: https://forum.dlang.org/post/kawfhminmtmwbmkzh...@forum.dlang.org On Monday, 19 June 2023 at 06:11:59 UTC, mw wrote: LDC - the LLVM D compiler (1.32.2): ``` main.d(32): Error: undefined identifier `vector` in module `core.stdcpp.vector`, did you mean enum member `MIctor`? ``` So what's wrong the LDC? how do I write `core.stdcpp.vector.vector` then? Currently, I was only able to get rid of this error using a fork of stdcpp still in progress in the standalone repository. Ref.: https://github.com/dlang/stdcpp/issues/5 What OS are you using? It's mentioned in the reference link. OS: ArchLinux
Re: Using C++ Classes From D: dmd cannot link, while ldc segfault
On Thursday, 25 January 2024 at 21:41:36 UTC, Matheus Catarino wrote: https://forum.dlang.org/post/kawfhminmtmwbmkzh...@forum.dlang.org On Monday, 19 June 2023 at 06:11:59 UTC, mw wrote: LDC - the LLVM D compiler (1.32.2): ``` main.d(32): Error: undefined identifier `vector` in module `core.stdcpp.vector`, did you mean enum member `MIctor`? ``` So what's wrong the LDC? how do I write `core.stdcpp.vector.vector` then? Currently, I was only able to get rid of this error using a fork of stdcpp still in progress in the standalone repository. Ref.: https://github.com/dlang/stdcpp/issues/5 What OS are you using?
Using C++ Classes From D: dmd cannot link, while ldc segfault
https://forum.dlang.org/post/kawfhminmtmwbmkzh...@forum.dlang.org On Monday, 19 June 2023 at 06:11:59 UTC, mw wrote: LDC - the LLVM D compiler (1.32.2): ``` main.d(32): Error: undefined identifier `vector` in module `core.stdcpp.vector`, did you mean enum member `MIctor`? ``` So what's wrong the LDC? how do I write `core.stdcpp.vector.vector` then? Currently, I was only able to get rid of this error using a fork of stdcpp still in progress in the standalone repository. Ref.: https://github.com/dlang/stdcpp/issues/5
[Issue 24327] LDC --nogc should work for scope class instance
https://issues.dlang.org/show_bug.cgi?id=24327 --- Comment #1 from a11e99z --- BTW I prefer: auto c = scope C(); cuz new X means heap/GC, scope means scope --
[Issue 24327] LDC --nogc should work for scope class instance
https://issues.dlang.org/show_bug.cgi?id=24327 a11e99z changed: What|Removed |Added Summary|LDC --nogc |LDC --nogc should work for ||scope class instance --
[Issue 24327] New: LDC --nogc
https://issues.dlang.org/show_bug.cgi?id=24327
Issue ID: 24327
Summary: LDC --nogc
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: minor
Priority: P1
Component: tools
Assignee: nob...@puremagic.com
Reporter: blac...@bk.ru
import core.stdc.stdio;
class C {
@nogc:
public:
this() { printf( "C.C\n"); }
~this() { printf( "C.~C\n"); }
}
void main() @nogc {
printf( "=> main\n");
scope(exit) printf( "<= main\n");
scope c = new C(); // LOC 14
}
//-
ldc2 file.d - OK
ldc2 --nogc file.d: file.d(14): Error: No implicit garbage collector calls
allowed with -nogc option enabled: `_d_callfinalizer`
shouldn't check/call GC for scope vars
--
Re: LDC 1.36.0
On Sat, Jan 06, 2024 at 06:03:54PM +, kinke via Digitalmars-d-announce
wrote:
> Glad to announce LDC 1.36.0. Major changes:
>
> * Based on D 2.106.1.
> * Support for LLVM 17; the prebuilt packages use v17.0.6.
> * New GDC-compatible CLI options `-fno-{exceptions,moduleinfo,rtti}` to
> selectively enable some `-betterC` effects.
> * Support for sample-based PGO via clang-compatible CLI option
> `-fprofile-sample-use` and `ldc-profgen` tool.
[...]
Awesome! Thanks to everyone involved in making this awesome compiler
available!
T
--
I've been around long enough to have seen an endless parade of magic new
techniques du jour, most of which purport to remove the necessity of thought
about your programming problem. In the end they wind up contributing one or
two pieces to the collective wisdom, and fade away in the rearview mirror. --
Walter Bright
LDC 1.36.0
Glad to announce LDC 1.36.0. Major changes:
* Based on D 2.106.1.
* Support for LLVM 17; the prebuilt packages use v17.0.6.
* New GDC-compatible CLI options
`-fno-{exceptions,moduleinfo,rtti}` to selectively enable some
`-betterC` effects.
* Support for sample-based PGO via clang-compatible CLI option
`-fprofile-sample-use` and `ldc-profgen` tool.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.36.0
Thanks to all contributors & sponsors!
Re: LDC 1.36.0-beta1
On Wednesday, 6 December 2023 at 15:10:14 UTC, d007 wrote: ```sh /ldc/bin/../import/core/internal/array/duplication.d(39): Error: appending to array in `res ~= cast(immutable(Column))e` requires the GC which is not available with -betterC ``` The code is used in ctfe function, I am not sure `~=` or `.idup` cause this problem. Thanks for testing. - This is a new check in the codegen layer; DMD has it, LDC was missing it so far. So if it does work with DMD, please file an LDC issue. - The expected root problem here is that the array-append lowering ends up being codegen'd, even though it's exclusively used for CTFE and so the template instances should be culled from codegen. (The logic for this is in the DMD frontend.)
Re: LDC 1.36.0-beta1
On Tuesday, 5 December 2023 at 00:31:20 UTC, kinke wrote:
Glad to announce the first beta for LDC 1.36. Major changes:
* Based on D 2.106.0.
* Support for LLVM 17; the prebuilt packages use v17.0.6.
* New GDC-compatible CLI options
`-fno-{exceptions,moduleinfo,rtti}` to selectively enable some
`-betterC` effects.
* Support for sample-based PGO via clang-compatible CLI option
`-fprofile-sample-use` and `ldc-profgen` tool.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.36.0-beta1
Please give this some extra regression testing if you find the
time, as it's the first LDC version with enforced opaque IR
pointers, and there might still be related, hard-to-find bugs
lurking in our codebase. You can e.g. run *optimized* unittests
via `DFLAGS=-O dub run -c unittest -b unittest`.
So please help test, and thanks to all contributors & sponsors!
After upgrade to this version. I get error for betterC.
```sh
/ldc/bin/../import/core/internal/array/duplication.d(39): Error:
appending to array in `res ~= cast(immutable(Column))e` requires
the GC which is not available with -betterC
```
The code is used in ctfe function, I am not sure `~=` or `.idup`
cause this problem.
LDC 1.36.0-beta1
Glad to announce the first beta for LDC 1.36. Major changes:
* Based on D 2.106.0.
* Support for LLVM 17; the prebuilt packages use v17.0.6.
* New GDC-compatible CLI options
`-fno-{exceptions,moduleinfo,rtti}` to selectively enable some
`-betterC` effects.
* Support for sample-based PGO via clang-compatible CLI option
`-fprofile-sample-use` and `ldc-profgen` tool.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.36.0-beta1
Please give this some extra regression testing if you find the
time, as it's the first LDC version with enforced opaque IR
pointers, and there might still be related, hard-to-find bugs
lurking in our codebase. You can e.g. run *optimized* unittests
via `DFLAGS=-O dub run -c unittest -b unittest`.
So please help test, and thanks to all contributors & sponsors!
[Issue 24254] LDC crash on Epyc Bergamo
https://issues.dlang.org/show_bug.cgi?id=24254 --- Comment #14 from Dlang Bot --- dlang/dmd pull request #15865 "Merge stable into master" was merged into master: - 27b891c0d810d1fcf88ff5e702e9d049232e8f8d by Martin Kinkelin: core.cpuid: Fix div-by-zero on AMD CPUs with 256 (physical?) cores See: https://en.wikipedia.org/wiki/CPUID#EAX=8008h:_Virtual_and_Physical_address_Sizes This *might* fix Issue 24254, although I'd expect the read value for that CPU to be 127 (*physical* cores minus 1), not the problematic 255. https://github.com/dlang/dmd/pull/15865 --
[Issue 24254] LDC crash on Epyc Bergamo
https://issues.dlang.org/show_bug.cgi?id=24254 --- Comment #13 from Dlang Bot --- @dkorpel created dlang/dmd pull request #15865 "Merge stable into master" mentioning this issue: - core.cpuid: Fix div-by-zero on AMD CPUs with 256 (physical?) cores See: https://en.wikipedia.org/wiki/CPUID#EAX=8008h:_Virtual_and_Physical_address_Sizes This *might* fix Issue 24254, although I'd expect the read value for that CPU to be 127 (*physical* cores minus 1), not the problematic 255. https://github.com/dlang/dmd/pull/15865 --
[Issue 24254] LDC crash on Epyc Bergamo
https://issues.dlang.org/show_bug.cgi?id=24254 --- Comment #12 from Dlang Bot --- @WalterBright updated dlang/dmd pull request #15864 "fix Issue 24262 - Assert error with bit fields" mentioning this issue: - core.cpuid: Fix div-by-zero on AMD CPUs with 256 (physical?) cores See: https://en.wikipedia.org/wiki/CPUID#EAX=8008h:_Virtual_and_Physical_address_Sizes This *might* fix Issue 24254, although I'd expect the read value for that CPU to be 127 (*physical* cores minus 1), not the problematic 255. https://github.com/dlang/dmd/pull/15864 --
[Issue 24254] LDC crash on Epyc Bergamo
https://issues.dlang.org/show_bug.cgi?id=24254 --- Comment #11 from Dlang Bot --- dlang/dmd pull request #15859 "[stable] core.cpuid: Fix div-by-zero on AMD CPUs with 256 (physical?) cores" was merged into stable: - edfa13e57de7b8597df2a95475179288c98cb25e by Martin Kinkelin: core.cpuid: Fix div-by-zero on AMD CPUs with 256 (physical?) cores See: https://en.wikipedia.org/wiki/CPUID#EAX=8008h:_Virtual_and_Physical_address_Sizes This *might* fix Issue 24254, although I'd expect the read value for that CPU to be 127 (*physical* cores minus 1), not the problematic 255. https://github.com/dlang/dmd/pull/15859 --
[Issue 24254] LDC crash on Epyc Bergamo
https://issues.dlang.org/show_bug.cgi?id=24254 --- Comment #10 from kinke --- (In reply to Jure Pečar from comment #8) > Keen eyes in easybuild community noticed that cpuid.d uses ubyte for > numcores in a couple of places […] Thank you, and please send those keen eyes my regards. :) --
[Issue 24254] LDC crash on Epyc Bergamo
https://issues.dlang.org/show_bug.cgi?id=24254 --- Comment #9 from Dlang Bot --- @kinke created dlang/dmd pull request #15859 "core.cpuid: Fix div-by-zero on AMD CPUs with 256 (physical?) cores" mentioning this issue: - core.cpuid: Fix div-by-zero on AMD CPUs with 256 (physical?) cores See: https://en.wikipedia.org/wiki/CPUID#EAX=8008h:_Virtual_and_Physical_address_Sizes This *might* fix Issue 24254, although I'd expect the read value for that CPU to be 127 (*physical* cores minus 1), not the problematic 255. https://github.com/dlang/dmd/pull/15859 --
[Issue 24254] LDC crash on Epyc Bergamo
https://issues.dlang.org/show_bug.cgi?id=24254 --- Comment #8 from Jure Pečar --- Keen eyes in easybuild community noticed that cpuid.d uses ubyte for numcores in a couple of places. For example, function getcacheinfoCPUID4 uses uint for numcores, but function getAMDcacheinfo uses ubyte. It also doesn't differentiate between cores and threads so I assume it walks all logical cpus there in the loop on lines 633-641. Bergamo has 128 cores, 256 threads, ubyte rolls over and then on line 659 you divide something by numcores. Boom. To test this hypothesis, I disabled SMT on one of the Bergamo nodes. Indeed, LDC then works as expected: # ldc2 Error: No source files So I'd say the fix is to just s/ubyte/uint/g on cpuid.d. And check if you do any similar things elsewhere. Thanks, --
[Issue 24254] LDC crash on Epyc Bergamo
https://issues.dlang.org/show_bug.cgi?id=24254 --- Comment #7 from Jure Pečar --- Here's a diff of `cpuid -1` output from 32c Genoa (-) and 128c Bergamo (+): @@ -3,16 +3,16 @@ version information (1/eax): processor type = primary processor (0) family = 0xf (15) - model = 0x1 (1) - stepping id = 0x1 (1) + model = 0x0 (0) + stepping id = 0x2 (2) extended family = 0xa (10) - extended model = 0x1 (1) + extended model = 0xa (10) (family synth) = 0x19 (25) - (model synth) = 0x11 (17) - (simple synth) = AMD EPYC (4th Gen) (Genoa B1) [Zen 4], 5nm + (model synth) = 0xa0 (160) + (simple synth) = AMD Ryzen (Bergamo) [Zen 4c], 5nm miscellaneous (1/ebx): - process local APIC physical ID = 0x10 (16) - maximum IDs for CPUs in pkg= 0x40 (64) + process local APIC physical ID = 0xd6 (214) + maximum IDs for CPUs in pkg= 0xff (255) CLFLUSH line size = 0x8 (8) brand index= 0x0 (0) brand id = 0x00 (0): unknown @@ -80,7 +80,7 @@ RDRAND instruction = true hypervisor guest status = false cache and TLB information (2): - processor serial number = 00A1-0F11---- + processor serial number = 00AA-0F02---- deterministic cache parameters (4): --- cache 0 --- cache type = no more caches (0) @@ -287,7 +287,7 @@ bit width of fixed counters = 0x0 (0) anythread deprecation= false x2APIC features / processor topology (0xb): - extended APIC ID = 16 + extended APIC ID = 214 --- level 0 --- level number = 0x0 (0) level type= thread (1) @@ -296,8 +296,8 @@ --- level 1 --- level number = 0x1 (1) level type= core (2) - bit width of level & previous levels = 0x6 (6) - number of logical processors at level = 0x40 (64) + bit width of level & previous levels = 0x8 (8) + number of logical processors at level = 0x100 (256) --- level 2 --- level number = 0x2 (2) level type= invalid (0) @@ -401,13 +401,13 @@ highest COS number supported = 0xf (15) extended processor signature (0x8001/eax): family/generation = 0xf (15) - model = 0x1 (1) - stepping id = 0x1 (1) + model = 0x0 (0) + stepping id = 0x2 (2) extended family = 0xa (10) - extended model = 0x1 (1) + extended model = 0xa (10) (family synth) = 0x19 (25) - (model synth) = 0x11 (17) - (simple synth) = AMD EPYC (4th Gen) (Genoa B1) [Zen 4], 5nm + (model synth) = 0xa0 (160) + (simple synth) = AMD Ryzen (Bergamo) [Zen 4c], 5nm extended feature flags (0x8001/edx): x87 FPU on chip = true virtual-8086 mode enhancement = true @@ -469,7 +469,7 @@ LLC performance counter extensions = true MWAITX/MONITORX supported = true Address mask extension support = true - brand = "AMD EPYC 9334 32-Core Processor" + brand = "AMD EPYC 9754 128-Core Processor " L1 TLB/cache information: 2M/4M pages & L1 TLB (0x8005/eax): instruction # entries = 0x40 (64) instruction associativity = 0xff (255) @@ -509,7 +509,7 @@ line size (bytes) = 0x40 (64) lines per tag = 0x1 (1) associativity = 0x9 (9) - size (in 512KB units) = 0x100 (256) + size (in 512KB units) = 0x200 (512) RAS Capability (0x8007/ebx): MCA overflow recovery support = true SUCCOR support= true @@ -566,8 +566,8 @@ branch sampling feature support = false (vuln to branch type confusion synth)= false Size Identifiers (0x8008/ecx): - number of threads = 0x40 (64) - ApicIdCoreIdSize= 0x6 (6) + number of threads = 0x100 (256) + ApicIdCoreIdSize= 0x8 (8) performance time-stamp counter size = 40 bits (0) Feature Extended Size (0x8008/edx): max page count for INVLPGB instruction = 0x7 (7) @@ -714,13 +714,13 @@ line size in bytes = 0x40 (64) physical line partitions= 0x1 (1) number of ways = 0x10 (16) - number of sets = 32768 + number of sets = 16384 write-back invalidate = true cache inclusive of lower levels = false - (synth size)
[Issue 24254] LDC crash on Epyc Bergamo
https://issues.dlang.org/show_bug.cgi?id=24254 --- Comment #6 from Jure Pečar --- I'll try to wade through this cpuid detection logic in an attempt to spot something. How would I narrow down the approximate location in the code where crash happens? FYI, Sambamba (and LDC) works fine on zen4 cpus such as Genoa and Genoa-X. /proc/cpuinfo reports identical cpuid level and flags for all three. Only difference for zen4c (Bergamo) should be smaller cache. Does that help us narrowing down the issue? --
[Issue 24254] LDC crash on Epyc Bergamo
https://issues.dlang.org/show_bug.cgi?id=24254 --- Comment #5 from kinke --- (In reply to Jure Pečar from comment #4) > Sorry this is my first time meeting D ecosystem, I'm having trouble > following your feedback. No worries. > So by "host compiler" you mean the previous version of LDC that was used to > build current version of LDC? Yes. > If that's the case, can you tell me which version of LDC started recognizing > and working with zen4c cpus? I don't know if it is working in current druntime. You could e.g. launch some Ubuntu/Debian container (min Ubuntu 20.04 for glibc) and try to run the official v1.35 in there. If there's no startup error, druntime v2.105 probably works. FWIW, the problematic module is https://github.com/dlang/dmd/blob/master/druntime/src/core/cpuid.d. As the name suggests, it uses/depends on the CPUID instruction. I can only tell you that everything works on my workstation, a Threadripper 3960X. --
[Issue 24254] LDC crash on Epyc Bergamo
https://issues.dlang.org/show_bug.cgi?id=24254 --- Comment #4 from Jure Pečar --- Sorry this is my first time meeting D ecosystem, I'm having trouble following your feedback. So by "host compiler" you mean the previous version of LDC that was used to build current version of LDC? If that's the case, can you tell me which version of LDC started recognizing and working with zen4c cpus? --
[Issue 24254] LDC crash on Epyc Bergamo
https://issues.dlang.org/show_bug.cgi?id=24254 kinke changed: What|Removed |Added Component|dmd |druntime OS|Linux |All --- Comment #3 from kinke --- Please leave my component and hardware changes in place, this has absolutely nothing to do with the DMD compiler. The official LDC binaries are compiled with itself, so v1.35 is built with v1.35. So from your description, we only know that `core.cpuid` of the LDC v1.24 druntime, i.e. druntime v2.094, doesn't support your CPU. But as your LDC v1.24 host compiler works, this means that the host druntime used for building that LDC v1.24 works. --
[Issue 24254] LDC crash on Epyc Bergamo
https://issues.dlang.org/show_bug.cgi?id=24254 Jure Pečar changed: What|Removed |Added Component|druntime|dmd OS|All |Linux --- Comment #2 from Jure Pečar --- I don't know what official binaries are built with, my build used gcc 12.3, llvm 16.0.6 and ldc 1.24 to build ldc 1.35. --
[Issue 24254] LDC crash on Epyc Bergamo
https://issues.dlang.org/show_bug.cgi?id=24254 kinke changed: What|Removed |Added CC||ki...@gmx.net Component|dmd |druntime OS|Linux |All --- Comment #1 from kinke --- According to the backtrace, the problem is in druntime's `core.cpuid` - of the **host compiler's** druntime used to build LDC. Which one did you use? The issue might have been fixed in recent druntime already. --
[Issue 24254] New: LDC crash on Epyc Bergamo
https://issues.dlang.org/show_bug.cgi?id=24254 Issue ID: 24254 Summary: LDC crash on Epyc Bergamo Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: major Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: jurij.pe...@embl.de Trying to figure out why Sambamba is crashing on Bergamo I noticed that issue is already present with LDC. Just trying to start it results in a stack trace: LDC 1.24 binary build: # ldc2 ldc2[0x33f03d4] Floating point exception (core dumped) LDC 1.35 built from source with Easybuild, LLVM 16.0.6, GCC 12.3 # ldc2 #0 0x743c6bbe llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/g/easybuild/x86_64/Rocky/8/genoa/software/LLVM/16.0.6-GCCcore-12.3.0/lib/libLLVM-16.so+0x918bbe) #1 0x743c459b SignalHandler(int) Signals.cpp:0:0 #2 0x73494cf0 __restore_rt (/lib64/libpthread.so.0+0x12cf0) #3 0x00c82ac4 _D4core5cpuid8cpuidX86FNbNiNeZv (/g/easybuild/x86_64/Rocky/8/znver4/software/LDC/1.35.0-GCCcore-12.3.0/bin/ldc2+0xc82ac4) #4 0x00c82c09 _D4core5cpuid26_sharedStaticCtor_L1065_C1FNbNiNeZv (/g/easybuild/x86_64/Rocky/8/znver4/software/LDC/1.35.0-GCCcore-12.3.0/bin/ldc2+0xc82c09) #5 0x00c9cbc9 _D2rt5minfo13rt_moduleCtorUZ14__foreachbody1MFKSQBu19sections_elf_shared3DSOZi (/g/easybuild/x86_64/Rocky/8/znver4/software/LDC/1.35.0-GCCcore-12.3.0/bin/ldc2+0xc9cbc9) #6 0x00c9db6a _D2rt19sections_elf_shared3DSO7opApplyFMDFKSQBqQBqQyZiZi (/g/easybuild/x86_64/Rocky/8/znver4/software/LDC/1.35.0-GCCcore-12.3.0/bin/ldc2+0xc9db6a) #7 0x00c93428 rt_init (/g/easybuild/x86_64/Rocky/8/znver4/software/LDC/1.35.0-GCCcore-12.3.0/bin/ldc2+0xc93428) #8 0x00c939ad _D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZv (/g/easybuild/x86_64/Rocky/8/znver4/software/LDC/1.35.0-GCCcore-12.3.0/bin/ldc2+0xc939ad) #9 0x00c93808 _d_run_main2 (/g/easybuild/x86_64/Rocky/8/znver4/software/LDC/1.35.0-GCCcore-12.3.0/bin/ldc2+0xc93808) #10 0x00c9365e _d_run_main (/g/easybuild/x86_64/Rocky/8/znver4/software/LDC/1.35.0-GCCcore-12.3.0/bin/ldc2+0xc9365e) #11 0x00797e4d main (/g/easybuild/x86_64/Rocky/8/znver4/software/LDC/1.35.0-GCCcore-12.3.0/bin/ldc2+0x797e4d) #12 0x72b4cd85 __libc_start_main (/lib64/libc.so.6+0x3ad85) #13 0x0079a12e _start (/g/easybuild/x86_64/Rocky/8/znver4/software/LDC/1.35.0-GCCcore-12.3.0/bin/ldc2+0x79a12e) Can't run binary release 1.35 as it requires glibc 2.29 (el8 only has 2.28). Does this stack trace ring any bells? Otherwise please let me know what further info would be useful to provide in order to fix this issue. It might be that root cause is further still, in llvm. Thanks, --
Re: D Metal Binding v2.0.6 - Support for LDC - Hipreme Engine is coming for iOS
Looking forward to supporting iOS! ;)
D Metal Binding v2.0.6 - Support for LDC - Hipreme Engine is coming for iOS
I've come to announce that, by following some old code on
arsd:simpledisplay (pre v11.0.0), Apple's documentation and this
amazing contribution from Jacob -
http://www.dsource.org/projects/dstep/wiki/ObjcBridge/BridgeInternals
I've removed all `extern(Objective-C)` code from the metal
bindings, and now, all of the Objective-C bridge code is
generated by using D's reflection.
So, given an example code like that:
```d
import core.attribute : selector;
extern(Objective-C):
class MTKView
{
///Creates a render pass descriptor to draw into the current
drawable.
@selector("currentRenderPassDescriptor")
MTLRenderPassDescriptor currentRenderPassDescriptor();
}
class MTKView2 : MTKView
{
///Creates a render pass descriptor to draw into the current
drawable.
@selector("currentRenderPassDescriptor2")
MTLRenderPassDescriptor currentRenderPassDescriptor2();
}
```
We have now:
mtkview.d
```d
module mtkview;
import objc.meta : selector;
@ObjectiveC final extern(C++):
class MTKView
{
///Creates a render pass descriptor to draw into the current
drawable.
@selector("currentRenderPassDescriptor")
MTLRenderPassDescriptor currentRenderPassDescriptor();
}
class MTKView2
{
mixin ObjcExtends!(MTKView);
///Creates a render pass descriptor to draw into the current
drawable.
@selector("currentRenderPassDescriptor2")
MTLRenderPassDescriptor currentRenderPassDescriptor2();
}
```
metal_gen.d
```d
module metal_gen;
import mtkview;
mixin ObjcLinkModule!(mtkview);
```
This is an example on how to actually get advantages from
separate compilation, compiling reflection code separately from
the interface code can lead to a lot better compilation speed.
The `mixin ObjcLinkModule` is used to iterate every `@ObjectiveC`
UDA, generating the implementation for each method defined in the
classes and interfaces. (Yes, you can implement the class methods
in other file).
The `final` is used to make D avoid virtual tables, since
Objective C objects doesn't follow D convention, this is needed
to get a namespace and a pointer. (With that, it is possible even
to make this valid code which doesn't segfault:
```d
import mtkview;
(cast(MTKView)(new int)).currentRenderPassDescriptor;
```
While `extern(C++)` is basically some way to save some memory by
not generating `TypeInfo ` and also, avoiding D dynamic casts,
whenever you need to cast, since they would give a segmentation
fault.
Although the interfacing code is not as clean as it was before,
for the user, the only thing that changes is that since all
classes are final, they aren't implicitly casted to their parent
class, so, an explicit cast is needed. It is a reasonable trade
for having support for iOS and M1, I guess. Though that happens,
in my entire engine I needed to fix like 2 lines of code after
all the change I've made to the binding, so, the front user will
still have a good looking code.
[D Metal Binding | Dub Package
](https://code.dlang.org/packages/d-metal-binding)
With all of this done, in the near future, iOS support, with
official LDC support on build selector for MacOS, will be done
for Hipreme Engine, which will make the engine supporting
literally every platform available for the common users :)
[Issue 24196] _d_arraysetassign(S[],S.init): it not work on struct when it is “@disable this(this)”, dmd 2.105.2/ldc 1.35
https://issues.dlang.org/show_bug.cgi?id=24196 dushibaiyu changed: What|Removed |Added Component|dmd |druntime --
[Issue 24196] New: _d_arraysetassign(S[],S.init): it not work on struct when it is “@disable this(this)”, dmd 2.105.2/ldc 1.35
https://issues.dlang.org/show_bug.cgi?id=24196
Issue ID: 24196
Summary: _d_arraysetassign(S[],S.init): it not work on struct
when it is “@disable this(this)”, dmd 2.105.2/ldc 1.35
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dushiba...@foxmail.com
the struct when it is “@disable this(this)”， init the struct array use “T[] =
T.init” it not work.
The S is @disable this(this); t[] = S.init. the t[0].i should be 42, but it was
not.
import std.stdio;
import core.memory;
struct S { int i = 42; @disable this(this); }
struct D { int i = 24;}
void main()
{
writeln("@disable this(this);");
auto ptr = GC.malloc(S.sizeof * 5);
S[] t = cast(S[])(ptr[0..S.sizeof * 5]);
writeln(t[0].i);
t[] = S.init;
// foreach(ref ts ; t){ // this is work to 42
// ts = S.init;
// }
writeln(t[0].i); // it should be 42, but it not!
// assert(t[0].i == 42);
writeln("this(this);");
ptr = GC.malloc(D.sizeof * 5);
D[] d = cast(D[])(ptr[0..D.sizeof * 5]);
writeln(d[0].i);
d[] = D.init;
writeln(d[0].i);
writeln("this(this); D2");
ptr = GC.malloc(D.sizeof * 5);
D[] d2 = cast(D[])(ptr[0..D.sizeof * 5]);
writeln(d2[0].i);
D td;
td.i = 78;
d2[] = td;
writeln(d2[0].i);
assert(d[0].i == 24);
assert(d2[0].i == 78);
assert(t[0].i == 42);
}
当禁用复制构造的结构体时。对其数组进行初始化（T[] = T.init），会失败。
--
Re: LDC 1.35.0
On Tuesday, 17 October 2023 at 18:29:49 UTC, Imperatorn wrote: On Tuesday, 17 October 2023 at 17:58:43 UTC, kinke wrote: On Tuesday, 17 October 2023 at 16:29:34 UTC, Imperatorn wrote: ``` lld-link: error: undefined symbol: _d_newitemT [...] ``` Sounds like you're using an older host compiler with newer target libs. That doesn't work, the host compiler needs to be upgraded too. [This is mentioned in https://wiki.dlang.org/Cross-compiling_with_LDC#Default_libraries.] Ok, thanks, I'll double check Also see my post here: https://forum.dlang.org/post/ynvrxlxczbzjghzek...@forum.dlang.org
Re: LDC 1.35.0
On Sunday, 15 October 2023 at 13:37:30 UTC, kinke wrote: Glad to announce LDC 1.35.0. Major changes: * Based on D 2.105.2+. * A few important ImportC fixes. * Fix GC2Stack optimization regression introduced in v1.24. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.35.0 Thanks to all contributors & sponsors! I got this error with [1.35](https://github.com/andrey-zherikov/argparse/actions/runs/6329005408/job/17881016327#step:4:24): ``` Exception Code: 0xC005 #0 0x7ff74f6b00d4 (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x2ee00d4) #1 0x7ff74f6b118d (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x2ee118d) #2 0x7ff74c8527c8 (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x827c8) #3 0x7ff74f9d33b1 (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x32033b1) #4 0x7ff74f64f052 (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x2e7f052) #5 0x7ff74f7601da (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x2f901da) #6 0x7ff74f75fe2f (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x2f8fe2f) #7 0x7ff74f760135 (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x2f90135) #8 0x7ff74f6484dd (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x2e784dd) #9 0x7ff74f9ff4c4 (C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe+0x322f4c4) #10 0x7ffc84be4de0 (C:\Windows\System32\KERNEL32.DLL+0x14de0) #11 0x7ffc859fed9b (C:\Windows\SYSTEM32\ntdll.dll+0x7ed9b) Error C:\hostedtoolcache\windows\dc\ldc2-1.35.0\x64\ldc2-1.35.0-windows-multilib\bin\ldc2.exe failed with exit code -1073741819. ``` There was no error with [1.34](https://github.com/andrey-zherikov/argparse/actions/runs/6165141917/job/16732347607) Does this look familiar?
[Issue 19929] LDC support dcompute codegen options?
https://issues.dlang.org/show_bug.cgi?id=19929 --- Comment #1 from dlangBugzillaToGithub --- THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/visuald/issues/252 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB --
[Issue 21769] Debugger customization methods do not work with LDC
https://issues.dlang.org/show_bug.cgi?id=21769 --- Comment #2 from dlangBugzillaToGithub --- THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/visuald/issues/255 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB --
Re: LDC 1.35.0
On Tuesday, 17 October 2023 at 17:58:43 UTC, kinke wrote: On Tuesday, 17 October 2023 at 16:29:34 UTC, Imperatorn wrote: ``` lld-link: error: undefined symbol: _d_newitemT [...] ``` Sounds like you're using an older host compiler with newer target libs. That doesn't work, the host compiler needs to be upgraded too. [This is mentioned in https://wiki.dlang.org/Cross-compiling_with_LDC#Default_libraries.] Ok, thanks, I'll double check
Re: LDC 1.35.0
On Tuesday, 17 October 2023 at 16:29:34 UTC, Imperatorn wrote: ``` lld-link: error: undefined symbol: _d_newitemT [...] ``` Sounds like you're using an older host compiler with newer target libs. That doesn't work, the host compiler needs to be upgraded too. [This is mentioned in https://wiki.dlang.org/Cross-compiling_with_LDC#Default_libraries.]
Re: LDC 1.35.0
On Tuesday, 17 October 2023 at 16:32:30 UTC, Imperatorn wrote: On Tuesday, 17 October 2023 at 16:29:34 UTC, Imperatorn wrote: ``` lld-link: error: undefined symbol: _d_newitemT [...] ``` Related to this? https://github.com/dlang/dmd/commit/159a8801a08eb14dd5c8ff2c88e1221975af7898 A lot of typos today, this happens in 1.35 (also)
Re: LDC 1.35.0
On Tuesday, 17 October 2023 at 16:29:34 UTC, Imperatorn wrote: ``` lld-link: error: undefined symbol: _d_newitemT referenced by /home/johan/dlang/ldc-1.34.0/bin/../import/std/array.d:3509 /home/johan/.dub/cache/related_optimized/~master/build/application-debug-gT8M_Ht4c9Ev0KJExAFkrA/related_optimized.obj:(_D3std5array__T8AppenderTAyaZQo6__ctorMFNaNbNcNeQxZSQByQBx__TQBuTQBoZQCc) referenced by /home/johan/dlang/ldc-1.34.0/bin/../import/std/array.d:3584 /home/johan/.dub/cache/related_optimized/~master/build/application-debug-gT8M_Ht4c9Ev0KJExAFkrA/related_optimized.obj:(_D3std5array__T8AppenderTAyaZQo13ensureAddableMFNaNbNfmZv) ``` Related to this? https://github.com/dlang/dmd/commit/159a8801a08eb14dd5c8ff2c88e1221975af7898
Re: LDC 1.35.0
On Tuesday, 17 October 2023 at 09:59:09 UTC, kinke wrote: On Monday, 16 October 2023 at 20:54:05 UTC, Sergey wrote: Does the build from GitHub now use LLVM's SPIR-V? It is not stated in release changes Yes, we've switched to the experimental LLVM target with our LDC-LLVM 16, in LDC v1.34 already. Get this now when cross-compiling from Linux to Windows _d_newitemT: ``` lld-link: error: undefined symbol: _d_newitemT [...] ``` Any input?
Re: LDC 1.35.0
On Monday, 16 October 2023 at 20:54:05 UTC, Sergey wrote: Does the build from GitHub now use LLVM's SPIR-V? It is not stated in release changes Yes, we've switched to the experimental LLVM target with our LDC-LLVM 16, in LDC v1.34 already.
Re: LDC 1.35.0
On Sunday, 15 October 2023 at 13:37:30 UTC, kinke wrote: Glad to announce LDC 1.35.0. Major changes: * Based on D 2.105.2+. * A few important ImportC fixes. * Fix GC2Stack optimization regression introduced in v1.24. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.35.0 Thanks to all contributors & sponsors! Thank you kinke and all related for release! Does the build from GitHub now use LLVM's SPIR-V? It is not stated in release changes
Re: LDC 1.35.0
On Sun, Oct 15, 2023 at 01:37:30PM +, kinke via Digitalmars-d-announce wrote: > Glad to announce LDC 1.35.0. Major changes: > > * Based on D 2.105.2+. > * A few important ImportC fixes. > * Fix GC2Stack optimization regression introduced in v1.24. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.35.0 > > Thanks to all contributors & sponsors! Awesome! Thanks to everyone involved in bringing us this awesome compiler. T -- Javascript is what you use to allow third party programs you don't know anything about and doing you know not what to run on your computer. -- Charles Hixson
Re: LDC 1.35.0
On Sunday, 15 October 2023 at 13:37:30 UTC, kinke wrote: Glad to announce LDC 1.35.0. Major changes: * Based on D 2.105.2+. * A few important ImportC fixes. * Fix GC2Stack optimization regression introduced in v1.24. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.35.0 Thanks to all contributors & sponsors! Cool ;)
Re: LDC 1.35.0
On Sunday, 15 October 2023 at 13:37:30 UTC, kinke wrote: Glad to announce LDC 1.35.0. Major changes: * Based on D 2.105.2+. * A few important ImportC fixes. * Fix GC2Stack optimization regression introduced in v1.24. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.35.0 Thanks to all contributors & sponsors! Nice! Thanks for all the work you do.
LDC 1.35.0
Glad to announce LDC 1.35.0. Major changes: * Based on D 2.105.2+. * A few important ImportC fixes. * Fix GC2Stack optimization regression introduced in v1.24. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.35.0 Thanks to all contributors & sponsors!
Re: LDC 1.35.0-beta1
On Thursday, 28 September 2023 at 11:13:20 UTC, Hipreme wrote: Hello, don't know when that happened but I'm happy to say that LDC 1.35.0 beta is building in half the time needed when compared against the version I was using (1.32.0). Same experience with the slow 1.32.0, there must be a performance bug in that version somewhere.
Re: LDC 1.35.0-beta1
On Monday, 11 September 2023 at 19:06:44 UTC, kinke wrote: Glad to announce the first beta for LDC 1.35. The single major change for now is the bump to D v2.105.1+. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.35.0-beta1 Please help test, and thanks to all contributors & sponsors! Getting better and better. Thanks
Re: LDC 1.35.0-beta1
On Monday, 11 September 2023 at 19:06:44 UTC, kinke wrote: Glad to announce the first beta for LDC 1.35. The single major change for now is the bump to D v2.105.1+. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.35.0-beta1 Please help test, and thanks to all contributors & sponsors! Hello, don't know when that happened but I'm happy to say that LDC 1.35.0 beta is building in half the time needed when compared against the version I was using (1.32.0). This is gonna be my default choice from now on :)
Re: LDC 1.35.0-beta1
On Monday, 11 September 2023 at 19:06:44 UTC, kinke wrote: Glad to announce the first beta for LDC 1.35. The single major change for now is the bump to D v2.105.1+. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.35.0-beta1 Please help test, and thanks to all contributors & sponsors! Thanks for the great work.
LDC 1.35.0-beta1
Glad to announce the first beta for LDC 1.35. The single major change for now is the bump to D v2.105.1+. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.35.0-beta1 Please help test, and thanks to all contributors & sponsors!
Re: LDC 1.34.0
On Tuesday, 29 August 2023 at 12:19:08 UTC, d007 wrote: Try link with LDC 1.34.0 release and lld linker, get this error: lld: error: unknown argument '-func-specialization-size-threshold=10' I can see there is `-Wl,-lto_library,/opt/local/ldc16/lib/libLTO-ldc.dylib -Wl,-mllvm,-func-specialization-size-threshold=10 ` passed into clang. turn out this is my scripts drop the -mllvm args pass to lld. now it work without problem.
Re: LDC 1.34.0
On Saturday, 26 August 2023 at 13:08:14 UTC, kinke wrote:
Glad to announce LDC 1.34.0. Major changes:
* Based on D 2.104.2.
* Support for LLVM 16, incl. v16.0.6 for the prebuilt packages.
Support for v9 and v10 was dropped.
* 64-bit RISC-V: Enable ISA extensions ('rv64gc') by default
when targeting an operating system.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.34.0
Thanks to all contributors & sponsors!
Try link with LDC 1.34.0 release and lld linker, get this error:
lld: error: unknown argument
'-func-specialization-size-threshold=10'
I can see there is
`-Wl,-lto_library,/opt/local/ldc16/lib/libLTO-ldc.dylib
-Wl,-mllvm,-func-specialization-size-threshold=10 `
passed into clang.
Re: LDC 1.34.0
On Monday, 28 August 2023 at 02:02:07 UTC, ryuukk_ wrote: These languages are stuck with LLVM and as a result are known for having very bad build speed The day D looses DMD will be the day i stop using D, DMD gives me fast build speed I don't understand the narrative that is being pushed to get rid of DMD, this sound like sabotage rather than improvement I guess no one try get rid off DMD, but put more resource into LDC. LDC is great for portability release/prod builds, for debug/fast iteration, DMD is unmatched, it's a competitive advantage only few languages have, having a fast compiler + LLVM based compiler is a killer combo, nobody should try to shut down DMD, it's beyond stupid Fun fact: Zig people are working on getting rid of LLVM and they are building their own backend, must be telling something, don't you think? ARM support for DMD would help making it future proof Zig made huge success with LLVM first, then try build they own backend. DMD is nice for play and testing, with ARM support will be great. but I hope ARM support not cost too much resource. (maybe use mold instead dmc tools)
Re: LDC 1.34.0
On Monday, 28 August 2023 at 02:02:07 UTC, ryuukk_ wrote: ARM support for DMD would help making it future proof +1
Re: LDC 1.34.0
On Sunday, 27 August 2023 at 09:10:14 UTC, drock wrote:
On Saturday, 26 August 2023 at 13:08:14 UTC, kinke wrote:
Glad to announce LDC 1.34.0. Major changes:
* Based on D 2.104.2.
* Support for LLVM 16, incl. v16.0.6 for the prebuilt
packages. Support for v9 and v10 was dropped.
* 64-bit RISC-V: Enable ISA extensions ('rv64gc') by default
when targeting an operating system.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.34.0
Thanks to all contributors & sponsors!
Thanks for the great work.
LDC team procuce the most important compiler with such less
manpower.
Unlike other new player (rust, zig, ponylang), they are focus
on llvm only backend and make great success.
The most dangerous crisis for dlang is keep loss users and
developers, there can be a thousand reasons for that. not
focus at one backend and imrpove it to the best is one reason.
for example Coroutines in LLVM can be add into dlang and work
with C++, there is simple no manpower for it.
These languages are stuck with LLVM and as a result are known for
having very bad build speed
The day D looses DMD will be the day i stop using D, DMD gives me
fast build speed
I don't understand the narrative that is being pushed to get rid
of DMD, this sound like sabotage rather than improvement
LDC is great for portability release/prod builds, for debug/fast
iteration, DMD is unmatched, it's a competitive advantage only
few languages have, having a fast compiler + LLVM based compiler
is a killer combo, nobody should try to shut down DMD, it's
beyond stupid
Fun fact: Zig people are working on getting rid of LLVM and they
are building their own backend, must be telling something, don't
you think?
ARM support for DMD would help making it future proof
Re: LDC 1.34.0
On Saturday, 26 August 2023 at 13:08:14 UTC, kinke wrote:
Glad to announce LDC 1.34.0. Major changes:
* Based on D 2.104.2.
* Support for LLVM 16, incl. v16.0.6 for the prebuilt packages.
Support for v9 and v10 was dropped.
* 64-bit RISC-V: Enable ISA extensions ('rv64gc') by default
when targeting an operating system.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.34.0
Thanks to all contributors & sponsors!
Thanks for the great work.
LDC team procuce the most important compiler with such less
manpower.
Unlike other new player (rust, zig, ponylang), they are focus on
llvm only backend and make great success.
The most dangerous crisis for dlang is keep loss users and
developers, there can be a thousand reasons for that. not focus
at one backend and imrpove it to the best is one reason.
for example Coroutines in LLVM can be add into dlang and work
with C++, there is simple no manpower for it.
Re: LDC 1.34.0-beta2
On Saturday, 26 August 2023 at 14:29:32 UTC, jmh530 wrote: On Friday, 18 August 2023 at 13:40:54 UTC, drug007 wrote: 18.08.2023 01:32, Guillaume Piolat пишет: [...] Let me improve it a little bit (some form of procrastination) [...] Sorry, but what are you improving here? Some people use email not the Markdown-enabled DFeed to read the messages.
Re: LDC 1.34.0-beta2
On Friday, 18 August 2023 at 13:40:54 UTC, drug007 wrote: 18.08.2023 01:32, Guillaume Piolat пишет: [...] Let me improve it a little bit (some form of procrastination) [...] Sorry, but what are you improving here?
LDC 1.34.0
Glad to announce LDC 1.34.0. Major changes:
* Based on D 2.104.2.
* Support for LLVM 16, incl. v16.0.6 for the prebuilt packages.
Support for v9 and v10 was dropped.
* 64-bit RISC-V: Enable ISA extensions ('rv64gc') by default when
targeting an operating system.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.34.0
Thanks to all contributors & sponsors!
Re: Spec for the ‘locality’ parameter to the LDC and GDC builtin magic functions for accessing special CPU prefetch instructions
On Saturday, 19 August 2023 at 19:23:38 UTC, Cecil Ward wrote: I’m trying to write a cross-platform function that gives access to the CPU’s prefetch instructions such as x86 prefetch0/1/2/prefetchnta and AAarch64 too. I’ve found that the GDC and LDC compilers provide builtin magic functions for this, and are what I need. I am trying to put together a plain-English detailed spec for the respective builtin magic functions. Have you found that? https://github.com/AuburnSounds/intel-intrinsics/blob/002da84215a58f098cee671c5ba4ab6052613865/source/inteli/xmmintrin.d#L1935C9-L1935C9
Re: Spec for the ‘locality’ parameter to the LDC and GDC builtin magic functions for accessing special CPU prefetch instructions
On Saturday, 19 August 2023 at 19:23:38 UTC, Cecil Ward wrote: I’m trying to write a cross-platform function that gives access to the CPU’s prefetch instructions such as x86 prefetch0/1/2/prefetchnta and AAarch64 too. I’ve found that the GDC and LDC compilers provide builtin magic functions for this, and are what I need. I am trying to put together a plain-English detailed spec for the respective builtin magic functions. My questions: Q1) I need to compare the spec for the GCC and LDC builtin magic functions’ "locality" parameter. Can anyone tell me if GDC and LDC have kept mutual compatibility here? I'd have thought GCC and LLVM have mutual compatibility thanks to a common target API in Intel's `_mm_prefetch()` function (and in fact, the magic locality numbers match `_MM_HINT_*` constants). ``` #define _MM_HINT_T0 1 #define _MM_HINT_T1 2 #define _MM_HINT_T2 3 #define _MM_HINT_NTA 0 ``` Q2) Could someone help me turn the GCC and LDC specs into english regarding the locality parameter ? - see (2) and (4) below. https://gcc.gnu.org/projects/prefetch.html Q3) Does the locality parameter determine which _level_ of the data cache hierarchy data is fetched into? Or is it always fetched into L1 data cache and the outer ones, and this parameter affects caches’ _future behaviour_? It really depends on the CPU, and what features it has. x86 SSE intrinsics are described in the x86 instruction manual, along with the meaning of T[012], and NTA. https://www.felixcloutier.com/x86/prefetchh Q3) Will these magic builtins work on AAarch64? It'll work on all targets that define a prefetch insn, or it'll be a no-op. Similarly one or both read-write or locality arguments might be ignored too.
Spec for the ‘locality’ parameter to the LDC and GDC builtin magic functions for accessing special CPU prefetch instructions
I’m trying to write a cross-platform function that gives access to the CPU’s prefetch instructions such as x86 prefetch0/1/2/prefetchnta and AAarch64 too. I’ve found that the GDC and LDC compilers provide builtin magic functions for this, and are what I need. I am trying to put together a plain-English detailed spec for the respective builtin magic functions. My questions: Q1) I need to compare the spec for the GCC and LDC builtin magic functions’ "locality" parameter. Can anyone tell me if GDC and LDC have kept mutual compatibility here? Q2) Could someone help me turn the GCC and LDC specs into english regarding the locality parameter ? - see (2) and (4) below. Q3) Does the locality parameter determine which _level_ of the data cache hierarchy data is fetched into? Or is it always fetched into L1 data cache and the outer ones, and this parameter affects caches’ _future behaviour_? Q3) Will these magic builtins work on AAarch64? Here’s what I’ve found so far 1. GCC builtin published by the D runtime: import gcc.simd : prefetch; prefetch!( rw, locality )( p ); 2. GCC: builtin_prefetch (const void *addr, ...) ¶ “This function is used to minimize cache-miss latency by moving data into a cache before it is accessed. You can insert calls to __builtin_prefetch into code for which you know addresses of data in memory that is likely to be accessed soon. If the target supports them, data prefetch instructions are generated. If the prefetch is done early enough before the access then the data will be in the cache by the time it is accessed. The value of addr is the address of the memory to prefetch. There are two optional arguments, rw and locality. The value of rw is a compile-time constant one or zero; one means that the prefetch is preparing for a write to the memory address and zero, the default, means that the prefetch is preparing for a read. The value locality must be a compile-time constant integer between zero and three. A value of zero means that the data has no temporal locality, so it need not be left in the cache after the access. A value of three means that the data has a high degree of temporal locality and should be left in all levels of cache possible. Values of one and two mean, respectively, a low or moderate degree of temporal locality. The default is three.” 3. declare void @llvm.prefetch(ptr , i32 , i32 , i32 4. Regarding llvm.prefetch() I found the following spec: “rw is the specifier determining if the fetch should be for a read (0) or write (1), and locality is a temporal locality specifier ranging from (0) - no locality, to (3) - extremely local keep in cache. The cache type specifies whether the prefetch is performed on the data (1) or instruction (0) cache. The rw, locality and cache type arguments must be constant integers.” 5. I also found this snippet https://dlang.org/phobos/core_builtins.html - which is great for the syntax of the call to the LDC builtin, but the call for GDC is no good as it lacks the parameters that I want. This D runtime routine might benefit from accepting all the parameters that GCC’s prefetch builtin takes. Many thanks in advance.
Re: LDC 1.34.0-beta2
18.08.2023 01:32, Guillaume Piolat пишет: On Thursday, 17 August 2023 at 18:24:41 UTC, kinke wrote: Glad to announce the second beta for LDC 1.34. Major change since beta1: LLVM 16 support, incl. v16.0.6 for the prebuilt packages. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.34.0-beta2 Please help test, and thanks to all contributors & sponsors! Just benchmarked 7 different LDC versions on a complex signal processing task. (mean of 77 measure for each result, arch x86_64, -mattr=+sse3, Win11): | LDC version | Speed vs baseline | LLVM version | Binary size | Release Date | | --- | --- | | | -- | | ldc-1.34.0-beta2.dll | 0% (baseline) | LLVM 16.0.6 | 3554 kb | 17th Aug 2023 | | ldc-1.33.0 | -0.72% | LLVM 15.0.7 |3578 kb | 23th Jul 2023 | | ldc-1.32.2 | -1% |LLVM 15.0.7 |3576 kb | 12th May 2023 | | ldc-1.31.0 | -2.6% |LLVM 14.0.3 |3569 kb | 11th Feb 2023 | | ldc-1.30.0 | -2.8% |LLVM 14.0.3 |3566 kb | 20th Jul 2022 | | ldc-1.29.0 | -2.7% |LLVM 13.0.1 |3555 kb | 8th Apr 2022 | | ldc-1.28.0 | -3.6% |LLVM 12.0.1 |3569 kb | 19th Oct 2021 | Let me improve it a little bit (some form of procrastination) | LDC | Speed vs | LLVM version | Binary | Release Date | | version | baseline | | size| | | --- | | | --- | - | | ldc-1.34.0- | 0% | LLVM 16.0.6 | 3554 kb | 17th Aug 2023 | | beta2.dll | | | | | | ldc-1.33.0 | -0.72% | LLVM 15.0.7 | 3578 kb | 23th Jul 2023 | | ldc-1.32.2 | -1% | LLVM 15.0.7 | 3576 kb | 12th May 2023 | | ldc-1.31.0 | -2.6%| LLVM 14.0.3 | 3569 kb | 11th Feb 2023 | | ldc-1.30.0 | -2.8%| LLVM 14.0.3 | 3566 kb | 20th Jul 2022 | | ldc-1.29.0 | -2.7%| LLVM 13.0.1 | 3555 kb | 8th Apr 2022 | | ldc-1.28.0 | -3.6%| LLVM 12.0.1 | 3569 kb | 19th Oct 2021 | *baseline is ldc-1.34.0-beta2.dll
Re: LDC 1.34.0-beta2
On Thursday, 17 August 2023 at 18:24:41 UTC, kinke wrote: Glad to announce the second beta for LDC 1.34. Major change since beta1: LLVM 16 support, incl. v16.0.6 for the prebuilt packages. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.34.0-beta2 Please help test, and thanks to all contributors & sponsors! Just benchmarked 7 different LDC versions on a complex signal processing task. (mean of 77 measure for each result, arch x86_64, -mattr=+sse3, Win11): | LDC version | Speed vs baseline | LLVM version | Binary size | Release Date | | --- | --- | | | -- | | ldc-1.34.0-beta2.dll | 0% (baseline) | LLVM 16.0.6 | 3554 kb | 17th Aug 2023 | | ldc-1.33.0 | -0.72% | LLVM 15.0.7 |3578 kb | 23th Jul 2023 | | ldc-1.32.2 | -1% |LLVM 15.0.7 |3576 kb | 12th May 2023 | | ldc-1.31.0 | -2.6% |LLVM 14.0.3 |3569 kb | 11th Feb 2023 | | ldc-1.30.0 | -2.8% |LLVM 14.0.3 |3566 kb | 20th Jul 2022 | | ldc-1.29.0 | -2.7% |LLVM 13.0.1 |3555 kb | 8th Apr 2022 | | ldc-1.28.0 | -3.6% |LLVM 12.0.1 |3569 kb | 19th Oct 2021 |
