[Issue 24291] ImportC: cannot compile janet.c
https://issues.dlang.org/show_bug.cgi?id=24291 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- Can you please try reducing this to the offending few lines of code? I don't have src/core/vm.c, and probably not exactly the same .h files you're using, either. --
[Issue 24293] ImportC: parallel compilation failure
https://issues.dlang.org/show_bug.cgi?id=24293 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- Try it serially. --
[Issue 24294] ImportC: required GCC version?
https://issues.dlang.org/show_bug.cgi?id=24294 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- Not sure what to do about this. compiler/src/dmd/link.d adds this switch, as it is necessary in order for druntime/src/importc.h to do its job. --
[Issue 24297] ImportC incompatible with glibc _FORTIFY_SOURCE
https://issues.dlang.org/show_bug.cgi?id=24297 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- The usual way to handle these sorts of extensions is to make macros for them that expand to nothing, and put those macros in druntime/src/importc.h. However, this bug report has insufficient information in it to do that, though I suspect that an: #undef _FORTIFY_SOURCE might work? --
[Issue 24299] The dmd's command line option "-run" should prefer dynamic linking with the Phobos library by default
https://issues.dlang.org/show_bug.cgi?id=24299 --- Comment #4 from Siarhei Siamashka --- (In reply to ryuukk_ from comment #2) > You mention go, but go does statically link everything > > So you are not matching go in your comparison, you are doing something > different to pretend it runs faster The DMD compiler doesn't produce any binary for the end users as a result of using "-run" option, so the choice of static or dynamic linking is a hidden internal implementation detail not visible to the end user. If you think that this kind of "cheating" is unfair to Go, then Go is already "cheating" to an even larger extent by using a custom non-standard format for the object files and relying on its own custom linker to process them. See https://go.googlesource.com/proposal/+/master/design/go13linker.md > The solution is to make phobos less bloated, let us not put the problem > under the carpet to pretend it's clean There's no such thing as "the solution" here. Compilation time can be reduced by doing multiple independent optimizations. Each of them contributes something. Currently there are many low hanging fruits. Even if you succeed in making Phobos less bloated, using dynamic linking instead of static linking will be still beneficial. --
[Issue 24299] The dmd's command line option "-run" should prefer dynamic linking with the Phobos library by default
https://issues.dlang.org/show_bug.cgi?id=24299 Adam D. Ruppe changed: What|Removed |Added CC||destructiona...@gmail.com --- Comment #3 from Adam D. Ruppe --- I think this is actually a pretty good idea. My reservation with dynamic linking in general is that it makes long term functionality and distribution harder; you have a larger sum of data to transfer and have the added difficulty of keeping versions in sync. But indeed, as you say with -run, you aren't keeping it long-term anyway, so it seems there's no downside to it. --
[Issue 24299] The dmd's command line option "-run" should prefer dynamic linking with the Phobos library by default
https://issues.dlang.org/show_bug.cgi?id=24299 ryuukk_ changed: What|Removed |Added CC||ryuukk@gmail.com --- Comment #2 from ryuukk_ --- You mention go, but go does statically link everything So you are not matching go in your comparison, you are doing something different to pretend it runs faster The solution is to make phobos less bloated, let us not put the problem under the carpet to pretend it's clean --
[Issue 24299] The dmd's command line option "-run" should prefer dynamic linking with the Phobos library by default
https://issues.dlang.org/show_bug.cgi?id=24299
--- Comment #1 from Siarhei Siamashka ---
For comparison, here's a similar test with Go (~143 ms):
```Go
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
```
$ go version
go version go1.21.4 linux/amd64
$ echo " " >> helloworld.go && time go run helloworld.go
hello world
real0m0.143s
The status quo is that `go run` is significantly faster today and getting
closer to its 143 ms should be a target for `dmd -run` as well.
--
[Issue 24299] New: The dmd's command line option "-run" should prefer dynamic linking with the Phobos library by default
https://issues.dlang.org/show_bug.cgi?id=24299
Issue ID: 24299
Summary: The dmd's command line option "-run" should prefer
dynamic linking with the Phobos library by default
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: siarhei.siamas...@hotmail.com
Consider the following small program:
```D
import std.stdio;
void main() {
writeln("Hello world!");
}
```
$ which dmd
/opt/dmd2-106.0/linux/bin64/dmd
$ time dmd -run helloworld.d
Hello world!
real0m0.414s
$ time dmd -defaultlib=libphobos2.a -run helloworld.d
Hello world!
real0m0.414s
$ time dmd -defaultlib=libphobos2.so -L-rpath=/opt/dmd2-106.0/linux/lib64 -run
helloworld.d
Hello world!
real0m0.188s
Linking libphobos2.a is more than twice slower than linking libphobos2.so (~414
ms vs. ~188 ms difference on my computer). While theoretically the users can
use any fancy command line options, in reality many of them just don't bother.
So the performance of just invoking `dmd -run helloworld.d` is bad out of the
box. But the compiled binary is immediately discarded after use and there are
no downsides to using dynamic linking in this scenario. So linking
libphobos2.so would be a more reasonable default configuration specifically for
the `-run` option.
I suggest to introduce additional sections "[RunEnvironment32]" and
"[RunEnvironment64]" in the "dmd.conf" file for the options specifically
tailored for the "-run" option. And then binary releases of the DMD compiler
could use these sections to provide fast `dmd -run` functionality out of the
box.
--
[Issue 13407] Better error message for static array size overflow
https://issues.dlang.org/show_bug.cgi?id=13407 Dennis changed: What|Removed |Added Status|NEW |RESOLVED CC||dkor...@live.nl Hardware|x86 |All Resolution|--- |FIXED OS|Windows |All --- Comment #2 from Dennis --- The error message is now a lot better: ``` `long[32768][32768]` size 262144 * 32768 exceeds 0x7fff size limit for static array ``` --
