Re: Bad codegen for comparison with postfix increment

[Iain Buclaw via D.gnu]

On Thursday, 9 May 2024 at 18:24:12 UTC, Iain Buclaw wrote:

On Wednesday, 8 May 2024 at 14:26:25 UTC, Paul Backus wrote:
When the following program is compiled with GDC 14.1, the 
assertion fails:


void main() {
int d = 42;
bool o = d > d++;
assert(o == false);
}

(Godbolt: https://d.godbolt.org/z/e63xbb9Td)

The assertion passes when the program is compiled with DMD 
2.108.0.


The same bug was recently reported for LDC: 
https://github.com/ldc-developers/ldc/issues/4651


I want to say that rewriting `d > d++` to `d++ < d` is a valid 
optimization.


See also `opCmp` rewriting `a < b` into `b.opCmp(a)`

https://dlang.org/spec/operatoroverloading.html#compare


Even when it doesn't swap order, DMD doesn't store the left hand 
of the expression to a target/temporary when operator overloading 
is involved.


https://d.godbolt.org/z/jYYr1WMhn


```
o = d.opCmp(d.opUnary!"++"())
```

Effectively
```
arg = d.opUnary!"++"(); // d mutates
o = d.opCmp(arg) > 0;   // true
```

Re: Bad codegen for comparison with postfix increment

[Iain Buclaw via D.gnu]

On Wednesday, 8 May 2024 at 14:26:25 UTC, Paul Backus wrote:
When the following program is compiled with GDC 14.1, the 
assertion fails:


void main() {
int d = 42;
bool o = d > d++;
assert(o == false);
}

(Godbolt: https://d.godbolt.org/z/e63xbb9Td)

The assertion passes when the program is compiled with DMD 
2.108.0.


The same bug was recently reported for LDC: 
https://github.com/ldc-developers/ldc/issues/4651


I want to say that rewriting `d > d++` to `d++ < d` is a valid 
optimization.


See also `opCmp` rewriting `a < b` into `b.opCmp(a)`

https://dlang.org/spec/operatoroverloading.html#compare

Bad codegen for comparison with postfix increment

[Paul Backus via D.gnu]

When the following program is compiled with GDC 14.1, the 
assertion fails:


void main() {
int d = 42;
bool o = d > d++;
assert(o == false);
}

(Godbolt: https://d.godbolt.org/z/e63xbb9Td)

The assertion passes when the program is compiled with DMD 
2.108.0.


The same bug was recently reported for LDC: 
https://github.com/ldc-developers/ldc/issues/4651

D1 compiler for Mac

[susugagalala via D.gnu]

Is the D1 compiler for Mac still available for download. If only 
the source code is available, how do I go about building a D1 
compiler for Mac?

Re: Would APEs work with D?

[Imperatorn via D.gnu]

On Friday, 22 March 2024 at 15:12:16 UTC, redthing1 wrote:

On Tuesday, 18 May 2021 at 14:43:52 UTC, Imperatorn wrote:

On Tuesday, 18 May 2021 at 08:40:10 UTC, Iain Buclaw wrote:
On Monday, 17 May 2021 at 11:08:33 UTC, Raimondo Mancino 
wrote:

[...]


The command would be pretty much the same as gcc (`-nostdinc 
-nostdlib`), but instead of `-include cosmopolitan.h`, you'd 
pass a cosmopolitan binding module (importC may solve the 
need for that), and a minimal (possibly empty) object.d to 
satisfy the compiler's need to have an object module.


Brace yourself... ImportC is coming.


Now that ImportC is here, may I ask: did you get this working? 
I'm also very interested in it.


I actually didn't find time to try it. But maybe someone else has?

Re: Xtensa support

[Witold Baryluk via D.gnu]

On Sunday, 14 April 2024 at 16:04:54 UTC, Matheus Catarino wrote:
Espressif/LLVM have xtensa-ABI (windowed) partial support, but 
GCC [upstream and fork] have both xtensa-ABI (call0 & windowed)


OK.

BTW. If you are on Debian / Ubuntu, xtensa cross compilers for 
C,C++,D are prepackaged in official repo. Package is named 
`gcc-xtensa-lx106` (it has all 3 language compilers).

Re: Xtensa support

[Matheus Catarino via D.gnu]

On Sunday, 14 April 2024 at 07:25:07 UTC, Witold Baryluk wrote:
On Friday, 12 April 2024 at 23:16:30 UTC, Matheus Catarino 
wrote:
I've recently seen support for different target architectures 
on https://explore.dgnu.org .
What is the status of Xtensa and xtensa-gnu support? Does it 
support both xtensa ABIs (call0 and windowed)?


Currently there is a need to fork espressif/LLVM when using 
ldc2. Is there a need to fork espressif crosstool-ng?


It works. I successfully run some code with it with gdc few 
years ago. But it is quite a work to map either reimplement all 
the APIs in D from scratch, but it can be done as everything is 
reasonably well documented. I only had some basic stuff like 
GPIO, very little of timers and uart. So no networking 
(possibly, but I had other things to do) or other stuff.



As of xtensa ABIs I have no idea. I didn't use espressif 
libraries. Should be possible tho.


Espressif/LLVM have xtensa-ABI (windowed) partial support, but 
GCC [upstream and fork] have both xtensa-ABI (call0 & windowed)


```bash
./gcc/esp32s3-gdc/bin/xtensa-esp32s3-elf-gdc --help=target
The following options are target specific:
  -mabi=call0 Use call0 ABI.
  -mabi=windowed  Use windowed registers ABI.
  -malways-memw   Always emit a MEMW before a 
load and after a store operation. Used to debug

  memory coherency issues.
  -mauto-litpools Relax literals in assembler and 
place them automatically in the text section.
  -mconst16   Use CONST16 instruction to load 
constants.
  -mdisable-hardware-atomics  Call built-in functions for 
atomic operations instead of using hardware atomic
  instructions. This option can 
be used if atomic operations on some memory
  regions need to be emulated in 
software.
  -mdynconfig=Directory or path to dynconfig 
library.
  -mextra-l32r-costs= Set extra memory access cost 
for L32R instruction, in clock-cycle units.
  -mfix-esp32-psram-cache-issue Work around a PSRAM cache 
issue in the ESP32 ECO1 chips.
  -mfix-esp32-psram-cache-strategy= Specify a psram cache fix 
strategy.
  -mforce-no-pic  Disable position-independent 
code (PIC) for use in OS kernel code.
  -mfused-maddSame as -ffp-contract=fast (or, 
in negated form, -ffp-contract=off).  Uses of

  this option are diagnosed.
  -mlongcalls Use indirect CALLXn 
instructions for large programs.
  -mlra   Use LRA instead of reload 
(transitional).
  -mno-serialize-volatile Do not serialize volatile 
memory references with MEMW instructions.
  -mtarget-align  Automatically align branch 
targets to reduce branch penalties.
  -mtext-section-literals Intersperse literal pools with 
code in the text section.


  Psram cache fix strategies (for use with 
-mfix-esp32-psram-cache-strategy= option):

dupldst memw nops
```

src: https://github.com/espressif/gcc
src: https://github.com/espressif/crosstool-ng

- **Note:** replace `--enable-languages=c,c++` to 
`--enable-languages=c,d` or add `d` after `c++`.


```bash
$> 
/root/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/xtensa-esp-elf-gcc -v

Using built-in specs.
COLLECT_GCC=/root/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/xtensa-esp-elf-gcc
COLLECT_LTO_WRAPPER=/root/.espressif/tools/xtensa-esp-elf/esp-13.2.0_20230928/xtensa-esp-elf/bin/../libexec/gcc/xtensa-esp-elf/13.2.0/lto-wrapper
Target: xtensa-esp-elf
Configured with: 
/builds/idf/crosstool-NG/.build/xtensa-esp-elf/src/gcc/configure 
--build=x86_64-build_pc-linux-gnu 
--host=x86_64-build_pc-linux-gnu --target=xtensa-esp-elf 
--prefix=/builds/idf/crosstool-NG/builds/xtensa-esp-elf 
--exec_prefix=/builds/idf/crosstool-NG/builds/xtensa-esp-elf 
--with-local-prefix=/builds/idf/crosstool-NG/builds/xtensa-esp-elf/xtensa-esp-elf --with-headers=/builds/idf/crosstool-NG/builds/xtensa-esp-elf/xtensa-esp-elf/include --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG esp-13.2.0_20230928' --disable-__cxa_atexit --enable-cxx-flags=-ffunction-sections --disable-libgomp --disable-libmudflap --disable-libmpx --disable-libssp --disable-libquadmath --disable-libquadmath-support --disable-libstdcxx-verbose --with-gmp=/builds/idf/crosstool-NG/.build/xtensa-esp-elf/buildtools --with-mpfr=/builds/idf/crosstool-NG/.build/xtensa-esp-elf/buildtools --with-mpc=/builds/idf/crosstool-NG/.build/xtensa-esp-elf/buildtools --with-isl=/builds/idf/crosstool-NG/.build/xtensa-esp-elf/buildtools --enable-lto --enable-target-optspace --without-long-double-128 --disable-nls --enable-multiarch --enable-languages=c,c++ --disable-libstdcxx-verbose --enable-threads=posix 

Re: Xtensa support

[Witold Baryluk via D.gnu]

On Friday, 12 April 2024 at 23:16:30 UTC, Matheus Catarino wrote:
I've recently seen support for different target architectures 
on https://explore.dgnu.org .
What is the status of Xtensa and xtensa-gnu support? Does it 
support both xtensa ABIs (call0 and windowed)?


Currently there is a need to fork espressif/LLVM when using 
ldc2. Is there a need to fork espressif crosstool-ng?


It works. I successfully run some code with it with gdc few years 
ago. But it is quite a work to map either reimplement all the 
APIs in D from scratch, but it can be done as everything is 
reasonably well documented. I only had some basic stuff like 
GPIO, very little of timers and uart. So no networking (possibly, 
but I had other things to do) or other stuff.



As of xtensa ABIs I have no idea. I didn't use espressif 
libraries. Should be possible tho.

Xtensa support

[Matheus Catarino via D.gnu]

I've recently seen support for different target architectures on 
https://explore.dgnu.org .
What is the status of Xtensa and xtensa-gnu support? Does it 
support both xtensa ABIs (call0 and windowed)?


Currently there is a need to fork espressif/LLVM when using ldc2. 
Is there a need to fork espressif crosstool-ng?

Re: Writing a GCC Front End with D!

[Jinftry via D.gnu]

On Saturday, 23 March 2024 at 17:41:15 UTC, Iain Buclaw wrote:

On Wednesday, 20 March 2024 at 13:19:27 UTC, Mahdis wrote:

[...]


To point out a few things you may not already be aware of / 
offer some thoughts in what I hope reads as neutral.


[...]

https://www.jinftry.com/

Re: Writing a GCC Front End with D!

[Iain Buclaw via D.gnu]

On Wednesday, 20 March 2024 at 13:19:27 UTC, Mahdis wrote:

Hi,

I have a question about the possibility of developing a new 
frontend language for GIMPLE in GCC using D instead of C++.




To point out a few things you may not already be aware of / offer 
some thoughts in what I hope reads as neutral.


I'm interested in exploring this possibility because D offers 
several advantages over C++, including:


1. Memory safety: D's garbage collector eliminates the need for 
manual memory management, which can help to prevent common 
errors such as memory leaks and dangling pointers.


GCC does have a garbage collector though (GGC), the interaction 
with it is to tag global variables and types with `GTY(())` to 
let it know where the roots are, and how to traverse them to look 
for more GC allocated memory.


2.Expressiveness: D's syntax is more concise and expressive 
than C++'s, which can make code easier to read, write, and 
maintain.


Can't argue with that. :-)

3. Modern features: D supports many modern programming 
features, such as generics, templates, and metaprogramming, 
which can be used to write more powerful and flexible code.




GCC has been embracing more of this though since making C++-11 
the bootstrap version, with some talk about bumping it to C++-14.


That's not to say this is a justification for not using D though, 
and using C++ traits can be described as jagged at best.


I believe that developing a new frontend language for GIMPLE in 
D would be a valuable contribution to the GCC project. It would 
allow developers to take advantage of D's many benefits while 
still using GCC's powerful optimization and code generation 
capabilities.




There is the binding problem though, as GCC internals do not have 
a stable layout. The API for interacting with GENERIC is just 
forest of macros (see gcc/tree.h) that hide all changes that are 
going on under the hood.  These will need to be accounted for, 
and I don't expect ImportC won't help you extract these 
definitions out of the C++ headers either.


I would be grateful for any information you can provide about 
the feasibility of this project. Thank you for your time and 
consideration.
Considering that I have no knowledge in this field, I would 
like to know if there are any limitations in this field.




Not saying it can't be done, but there's an extra maintenance 
needed to keep the front-end written in D in sync with the GCC 
middle-end. Gnat achieves this with a library named Gigi to bind 
these as functions callable from Ada.


Think something like:
```d
extern(C++) ref tree type_attributes(tree);
```

```c++
tree _attributes(tree node) { return TYPE_ATTRIBUTES(node); }
```

Though I don't actually know to what extent they do something 
like the above, or whether the GCC interface is even more high 
level.


I've also seen an Algol front-end for GCC written in Algol 
itself, and the author of chose to translate all macros it used 
into Algol directly, the downside then is that it's tying itself 
to a specific version of GCC.


Writing a GCC plugin in D might be a good idea to test the waters 
for whichever method works best before going full language 
front-end.


Iain.

Re: Would APEs work with D?

[redthing1 via D.gnu]

On Tuesday, 18 May 2021 at 14:43:52 UTC, Imperatorn wrote:

On Tuesday, 18 May 2021 at 08:40:10 UTC, Iain Buclaw wrote:

On Monday, 17 May 2021 at 11:08:33 UTC, Raimondo Mancino wrote:

[...]


The command would be pretty much the same as gcc (`-nostdinc 
-nostdlib`), but instead of `-include cosmopolitan.h`, you'd 
pass a cosmopolitan binding module (importC may solve the need 
for that), and a minimal (possibly empty) object.d to satisfy 
the compiler's need to have an object module.


Brace yourself... ImportC is coming.


Now that ImportC is here, may I ask: did you get this working? 
I'm also very interested in it.

Writing a GCC Front End with D!

[Mahdis via D.gnu]

Hi,

I have a question about the possibility of developing a new 
frontend language for GIMPLE in GCC using D instead of C++.


I'm interested in exploring this possibility because D offers 
several advantages over C++, including:


1. Memory safety: D's garbage collector eliminates the need for 
manual memory management, which can help to prevent common errors 
such as memory leaks and dangling pointers.
2.Expressiveness: D's syntax is more concise and expressive than 
C++'s, which can make code easier to read, write, and maintain.
3. Modern features: D supports many modern programming features, 
such as generics, templates, and metaprogramming, which can be 
used to write more powerful and flexible code.


I believe that developing a new frontend language for GIMPLE in D 
would be a valuable contribution to the GCC project. It would 
allow developers to take advantage of D's many benefits while 
still using GCC's powerful optimization and code generation 
capabilities.


I would be grateful for any information you can provide about the 
feasibility of this project. Thank you for your time and 
consideration.
Considering that I have no knowledge in this field, I would like 
to know if there are any limitations in this field.


Sincerely,

Mahdis

Re: GDC on CYGWIN available

[Tim Stahlhut via D.gnu]

On Tuesday, 22 August 2023 at 15:25:25 UTC, jicman wrote:
On Wednesday, 7 June 2023 at 18:04:43 UTC, Ferhat Kurtulmuş 
wrote:



[...]


Ok, maybe we can get this fixed, somehow. :-)

[...]


Any progress on getting cygwin GDC to work?

Tim S.

Re: Create a self contained object file like fat jars from java

[Richard (Rikki) Andrew Cattermole via D.gnu]

On 15/01/2024 1:23 AM, pizza_dox_ wrote:
On Sunday, 14 January 2024 at 11:54:09 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

On 15/01/2024 12:47 AM, pizza_dox_ wrote:
OK to make it clear. I wanted to call d from c so that I can write a 
n64 game with d. But compiling the d object files while using higher 
features like classes, resulted in missing dependencys. So because 
GCC doesnt understands d I need an object file which has everything 
included d needs to run. Thats my understanding of this situation.


My understanding is druntime is not ported to that platform.

Too limited in resources.

Getting a static library with all dependencies would not help you here.

But yes, GCC does understand D, using GDC which is built on top (same 
frontend as DMD and LDC).


You are either stuck using -betterC which does not support 
``extern(D)`` classes, but does have ``extern(C++)`` classes. Or by 
using a custom runtime which you will likely have to write yourself 
and will likely break between compiler releases.


Thank you for the clarification.
Are such things as string so platform dependent in d or the stuff for 
the class and interface declarations that they aren't cross platform? I 
meant the gcc used by the n64 toolchain (libdragon).


A string in D is a slice. A pointer + length. This is entirely platform 
agnostic.


A dynamic array, is a slice, backed by the GC. This requires the GC and 
with that druntime. Which means you cannot append to a slice without 
druntime.


Classes require a ton of infrastructure to work. They are not purely a 
compilation construct.

Re: Create a self contained object file like fat jars from java

[pizza_dox_9999 via D.gnu]

On Sunday, 14 January 2024 at 11:54:09 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

On 15/01/2024 12:47 AM, pizza_dox_ wrote:
OK to make it clear. I wanted to call d from c so that I can 
write a n64 game with d. But compiling the d object files 
while using higher features like classes, resulted in missing 
dependencys. So because GCC doesnt understands d I need an 
object file which has everything included d needs to run. 
Thats my understanding of this situation.


My understanding is druntime is not ported to that platform.

Too limited in resources.

Getting a static library with all dependencies would not help 
you here.


But yes, GCC does understand D, using GDC which is built on top 
(same frontend as DMD and LDC).


You are either stuck using -betterC which does not support 
``extern(D)`` classes, but does have ``extern(C++)`` classes. 
Or by using a custom runtime which you will likely have to 
write yourself and will likely break between compiler releases.


Thank you for the clarification.
Are such things as string so platform dependent in d or the stuff 
for the class and interface declarations that they aren't cross 
platform? I meant the gcc used by the n64 toolchain (libdragon).

Re: Create a self contained object file like fat jars from java

[Richard (Rikki) Andrew Cattermole via D.gnu]

On 15/01/2024 12:47 AM, pizza_dox_ wrote:
OK to make it clear. I wanted to call d from c so that I can write a n64 
game with d. But compiling the d object files while using higher 
features like classes, resulted in missing dependencys. So because GCC 
doesnt understands d I need an object file which has everything included 
d needs to run. Thats my understanding of this situation.


My understanding is druntime is not ported to that platform.

Too limited in resources.

Getting a static library with all dependencies would not help you here.

But yes, GCC does understand D, using GDC which is built on top (same 
frontend as DMD and LDC).


You are either stuck using -betterC which does not support ``extern(D)`` 
classes, but does have ``extern(C++)`` classes. Or by using a custom 
runtime which you will likely have to write yourself and will likely 
break between compiler releases.

Re: Create a self contained object file like fat jars from java

[pizza_dox_9999 via D.gnu]

OK to make it clear. I wanted to call d from c so that I can 
write a n64 game with d. But compiling the d object files while 
using higher features like classes, resulted in missing 
dependencys. So because GCC doesnt understands d I need an object 
file which has everything included d needs to run. Thats my 
understanding of this situation.

Re: Create a self contained object file like fat jars from java

[Richard (Rikki) Andrew Cattermole via D.gnu]

On 15/01/2024 12:42 AM, pizza_dox_ wrote:
On Sunday, 14 January 2024 at 10:05:12 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

On 08/01/2024 7:14 AM, Renato wrote:

On Friday, 5 January 2024 at 22:10:31 UTC, pizza_dox_ wrote:

[...]


Did you try using dub and specifying `targetType="staticLibrary"`?

See https://dub.pm/dub-reference/build_settings/#targetpath

Even if you just want the right flags, this could help as you can 
"ask" dub to print the flags it's using with `dub build -v`.


Dub's static library target type does not include dependencies or 
druntime/phobos.


Typically static libraries do not combine to produce a bigger static 
library.


But thats what I need and want.


Combining of static libraries is not specific to D.

Although you're going to need to figure out how to get a list of all the 
static libraries you want to combine. The actual combination should be 
pretty standard.

Re: Create a self contained object file like fat jars from java

[pizza_dox_9999 via D.gnu]

On Sunday, 14 January 2024 at 10:05:12 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

On 08/01/2024 7:14 AM, Renato wrote:
On Friday, 5 January 2024 at 22:10:31 UTC, pizza_dox_ 
wrote:

[...]


Did you try using dub and specifying 
`targetType="staticLibrary"`?


See https://dub.pm/dub-reference/build_settings/#targetpath

Even if you just want the right flags, this could help as you 
can "ask" dub to print the flags it's using with `dub build 
-v`.


Dub's static library target type does not include dependencies 
or druntime/phobos.


Typically static libraries do not combine to produce a bigger 
static library.


But thats what I need and want.

Re: Create a self contained object file like fat jars from java

[Richard (Rikki) Andrew Cattermole via D.gnu]

On 08/01/2024 7:14 AM, Renato wrote:

On Friday, 5 January 2024 at 22:10:31 UTC, pizza_dox_ wrote:
Hi, I am trying with gdc to create the equivalent of a fat jar. So for 
that I would need the standard dlang library included in the object or 
library file. Does somebody know the needed gdc flags?

I am using mips64-linux-gnuabi64-gdc-12.
pizza_dox_


Did you try using dub and specifying `targetType="staticLibrary"`?

See https://dub.pm/dub-reference/build_settings/#targetpath

Even if you just want the right flags, this could help as you can "ask" 
dub to print the flags it's using with `dub build -v`.


Dub's static library target type does not include dependencies or 
druntime/phobos.


Typically static libraries do not combine to produce a bigger static 
library.

Re: Create a self contained object file like fat jars from java

[Renato via D.gnu]

On Sunday, 14 January 2024 at 09:36:16 UTC, pizza_dox_ wrote:

On Sunday, 7 January 2024 at 18:14:12 UTC, Renato wrote:
On Friday, 5 January 2024 at 22:10:31 UTC, pizza_dox_ 
wrote:
Hi, I am trying with gdc to create the equivalent of a fat 
jar. So for that I would need the standard dlang library 
included in the object or library file. Does somebody know 
the needed gdc flags?

I am using mips64-linux-gnuabi64-gdc-12.
pizza_dox_


Did you try using dub and specifying 
`targetType="staticLibrary"`?


See https://dub.pm/dub-reference/build_settings/#targetpath

Even if you just want the right flags, this could help as you 
can "ask" dub to print the flags it's using with `dub build 
-v`.


Thank you for the information. Sadly nothing for gdc directly. 
But how is dub solving my problem? Is the buildstep creating a 
"fat jar". So instead of compiling multiple .d files with gdc I 
would only compile the "fat jar" from dub?


I think you misunderstood me. `dub` is the D's build system and 
it "knows" how to call the D compilers, including gdc.


When you tell dub to build a static library (equivalent to "fat 
jar" for D) it will use whatever compiler options are needed to 
do so... you can run `dub build -v -release --compiler=gdc` to 
see which compiler options it's using to invoke gdc, and then you 
can just drop dub if you don't need it (though it's very useful 
to have).

Re: Create a self contained object file like fat jars from java

[pizza_dox_9999 via D.gnu]

On Sunday, 7 January 2024 at 18:14:12 UTC, Renato wrote:

On Friday, 5 January 2024 at 22:10:31 UTC, pizza_dox_ wrote:
Hi, I am trying with gdc to create the equivalent of a fat 
jar. So for that I would need the standard dlang library 
included in the object or library file. Does somebody know the 
needed gdc flags?

I am using mips64-linux-gnuabi64-gdc-12.
pizza_dox_


Did you try using dub and specifying 
`targetType="staticLibrary"`?


See https://dub.pm/dub-reference/build_settings/#targetpath

Even if you just want the right flags, this could help as you 
can "ask" dub to print the flags it's using with `dub build -v`.


Thank you for the information. Sadly nothing for gdc directly. 
But how is dub solving my problem? Is the buildstep creating a 
"fat jar". So instead of compiling multiple .d files with gdc I 
would only compile the "fat jar" from dub?

Re: gdc latest Cygwin

[Iain Buclaw via D.gnu]

On Tuesday, 2 January 2024 at 03:14:05 UTC, Siarhei Siamashka 
wrote:
On Tuesday, 2 January 2024 at 01:49:47 UTC, Siarhei Siamashka 
wrote:
Thanks for giving the Windows users this hint. It's much 
better than the radio silence.


And by the way, I'm not being sarcastic. Having any hints is 
really useful for the potential contributors.


To try and encourage you, here's the `core.stdc` part of the 
bindings. Someone's still got to do the `core.sys` bit though, 
and do the validating of the druntime parts that depend on these.


https://github.com/dlang/dmd/pull/16022

Wouldn't hold my breath to see the second/third parts of newlib 
support this side of the month.

Re: Create a self contained object file like fat jars from java

[Renato via D.gnu]

On Friday, 5 January 2024 at 22:10:31 UTC, pizza_dox_ wrote:
Hi, I am trying with gdc to create the equivalent of a fat jar. 
So for that I would need the standard dlang library included in 
the object or library file. Does somebody know the needed gdc 
flags?

I am using mips64-linux-gnuabi64-gdc-12.
pizza_dox_


Did you try using dub and specifying `targetType="staticLibrary"`?

See https://dub.pm/dub-reference/build_settings/#targetpath

Even if you just want the right flags, this could help as you can 
"ask" dub to print the flags it's using with `dub build -v`.

Create a self contained object file like fat jars from java

[pizza_dox_9999 via D.gnu]

Hi, I am trying with gdc to create the equivalent of a fat jar. 
So for that I would need the standard dlang library included in 
the object or library file. Does somebody know the needed gdc 
flags?

I am using mips64-linux-gnuabi64-gdc-12.
pizza_dox_

Re: gdc latest Cygwin

[Siarhei Siamashka via D.gnu]

On Tuesday, 2 January 2024 at 01:49:47 UTC, Siarhei Siamashka 
wrote:
Thanks for giving the Windows users this hint. It's much better 
than the radio silence.


And by the way, I'm not being sarcastic. Having any hints is 
really useful for the potential contributors.

Re: gdc latest Cygwin

[Siarhei Siamashka via D.gnu]

On Tuesday, 2 January 2024 at 00:07:39 UTC, Iain Buclaw wrote:
Might not be best to wait for me to port it, as anything on 
Windows tends to get sidetracked given that I have no access to 
any machine running it.


I have an obsolete 32-bit Windows 7 preinstalled on a single-core 
Atom 1.66GHz netbook with 1GB RAM collecting dust somewhere in my 
closet. So I'm surely in a somewhat better position than you when 
it comes to having access to machines running Windows. But it's 
hardly suitable for developing any modern software on it 
nowadays. Github CI jobs support Windows and that's what I'm 
realistically using for testing my DUB packages on this platform.


The bulk of the work is really in adding CRuntime_Newlib 
support to upstream druntime, then there should be nothing 
blocking you from building the library.


Thanks for giving the Windows users this hint. It's much better 
than the radio silence.

Re: gdc latest Cygwin

[Iain Buclaw via D.gnu]

On Monday, 1 January 2024 at 23:59:38 UTC, Siarhei Siamashka 
wrote:

On Monday, 1 January 2024 at 23:49:41 UTC, tdm3j2bqz wrote:

Is gdc known to work on Cygwin?


There's already a discussion thread about this: 
https://forum.dlang.org/thread/ndoljmmelsslcjvrs...@forum.dlang.org


Might not be best to wait for me to port it, as anything on 
Windows tends to get sidetracked given that I have no access to 
any machine running it.


The bulk of the work is really in adding CRuntime_Newlib support 
to upstream druntime, then there should be nothing blocking you 
from building the library.

Re: gdc latest Cygwin

[Siarhei Siamashka via D.gnu]

On Monday, 1 January 2024 at 23:49:41 UTC, tdm3j2bqz wrote:

Is gdc known to work on Cygwin?


There's already a discussion thread about this: 
https://forum.dlang.org/thread/ndoljmmelsslcjvrs...@forum.dlang.org

gdc latest Cygwin

[tdm3j2bqz via D.gnu]

This is from a regular Cygwin package called gcc-gdc installed 
after the gcc-core package was installed.

```
$ gdc hello.d -o hello
d21: error: cannot find source code for runtime library file 
'object.d'
d21: note: dmd might not be correctly installed. Run 'dmd -man' 
for installation instructions.

d21: note: config file: not found

$ dmd
-bash: dmd: command not found

$ which gdc
/usr/bin/gdc

$ gdc --version
gdc (GCC) 11.4.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE.

```
Is gdc known to work on Cygwin?

Re: etc.c.sqlite3 missing from GDC phobos since gcc-12?

[singingbush via D.gnu]

On Friday, 11 August 2023 at 05:50:43 UTC, Joe Kappus wrote:
I noticed this yesterday when trying to package the dlang 
onedrive client in Gentoo with GDC 13.2 and it failed since it 
requires this.


It appears to have been removed when gdc became self-hosting in 
gcc during the gcc-12 release cycle.


There when it was present: 
https://github.com/gcc-mirror/gcc/tree/releases/gcc-11.2.0/libphobos/src/etc/c
Gone now: 
https://github.com/gcc-mirror/gcc/tree/releases/gcc-13.2.0/libphobos/src/etc/c
Still in dmd: 
https://github.com/dlang/phobos/blob/master/etc/c/sqlite3.d


I've asked in the #d IRC channel on Libera, and their guess was 
it was omitted by mistake so I'm writing in to verify: Would 
you know whether it's a bug and will return or otherwise why it 
got dropped? Thanks!


DDBC and Hibernated are affected by this. Being unable to import 
`etc.c.sqlite3` means that the CI for ddbc & Hibernated cannot be 
run using gdc.


```
source/ddbc/drivers/sqliteddbc.d:48:12: error: unable to read 
module ‘sqlite3’

   48 | import etc.c.sqlite3;
  |^
source/ddbc/drivers/sqliteddbc.d:48:12: note: Expected 
'etc/c/sqlite3.d' or 'etc/c/sqlite3/package.d' in one of the 
following import paths:

   48 | import etc.c.sqlite3;
  |^
import path[0] = /usr/lib/gcc/x86_64-linux-gnu/12/include/d
```

https://github.com/buggins/ddbc/issues/122
https://github.com/buggins/hibernated/issues/83

Re: cross-GDC for tiny embedded Linux

[Dmitry Ponyatov via D.gnu]

Did you solve it?


No, project delayed until I'll have enough deep qualification in 
system-level D coding

Re: cross-GDC for tiny embedded Linux

[Imperatorn via D.gnu]

On Wednesday, 25 October 2023 at 17:11:11 UTC, Dmitry Ponyatov 
wrote:
How/where are you referencing mmap64? Could some include be 
missing or path issue?


ref/gcc-12.3.0/libphobos/libdruntime/core/internal/gc/os.d:145
ref/gcc-12.3.0/libphobos/libdruntime/core/thread/fiber.d:1050
host/lib/gcc/i686-linux-musl/12.3.0/../../../../i686-linux-musl/lib/libgphobos.a(os.o)
etc


Did you solve it?

Re: cross-GDC for tiny embedded Linux

[Dmitry Ponyatov via D.gnu]

How/where are you referencing mmap64? Could some include be 
missing or path issue?


ref/gcc-12.3.0/libphobos/libdruntime/core/internal/gc/os.d:145
ref/gcc-12.3.0/libphobos/libdruntime/core/thread/fiber.d:1050
host/lib/gcc/i686-linux-musl/12.3.0/../../../../i686-linux-musl/lib/libgphobos.a(os.o)
etc

Re: cross-GDC for tiny embedded Linux

[Imperatorn via D.gnu]

On Sunday, 22 October 2023 at 21:52:18 UTC, Dmitry Ponyatov wrote:

[...]


fixed by moving to `musl` usage -- not a surprise that `uClibc` 
becomes obsoleted libc comparing their compilation time, 
configuration complexity, and incompatibility with modern 
toolchains


[...]


How/where are you referencing mmap64? Could some include be 
missing or path issue?

Re: cross-GDC for tiny embedded Linux

[Dmitry Ponyatov via D.gnu]

Here the next problem of building `gcc-12.3.0` with 
`uClibc-ng-1.0.44` (i386 target):


fixed by moving to `musl` usage -- not a surprise that `uClibc` 
becomes obsoleted libc comparing their compilation time, 
configuration complexity, and incompatibility with modern 
toolchains


But the next linking error, what is going to be?

```
/home/ponyatov/player/host/lib/gcc/i686-linux-musl/12.3.0/../../../../i686-linux-musl/bin/ld:
 
/home/ponyatov/player/host/lib/gcc/i686-linux-musl/12.3.0/../../../../i686-linux-musl/lib/libgphobos.a(os.o):
 in function `_D4core8internal2gc2os10os_mem_mapFNbNikbZPv':
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/internal/gc/os.d:145:(.text._D4core8internal2gc2os10os_mem_mapFNbNikbZPv+0x22):
 undefined reference to `mmap64'
/home/ponyatov/player/host/lib/gcc/i686-linux-musl/12.3.0/../../../../i686-linux-musl/bin/ld:
 
/home/ponyatov/player/host/lib/gcc/i686-linux-musl/12.3.0/../../../../i686-linux-musl/lib/libgphobos.a(fiber.o):/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/thread/fiber.d:1050:
 more undefined references to `mmap64' follow
collect2: error: ld returned 1 exit status
```

riscv-unknown-elf-as wont accept .section

[Paul via D.gnu]

I'm following a tutorial that offers this file (start.s),

.section ".text.boot"

.globl _start
_start:
   la sp, _stack_start
   call dstart
_hlt:
   j _hlt  # jump to _hlt

...assembled with this,
**riscv64-unknown-elf-as  -mno-relax -march=rv64imac start.s -c 
-o start.o**


...which responds with,
**start.s: Assembler messages:**
**start.s:1: Error: unrecognized opcode `.section ".text.boot"'**

The only way I can get start.s to compile is by removing these 
first three lines:


.section ".text.boot"

.globl _start


Any help would be appreciated.

Re: cross-GDC for tiny embedded Linux

[Dmitry Ponyatov via D.gnu]

Here the next problem of building `gcc-12.3.0` with 
`uClibc-ng-1.0.44` (i386 target):

```
libtool: compile:  
/home/ponyatov/player/tmp/gcc-12.3.0-1/./gcc/gdc 
-B/home/ponyatov/player/tmp/gcc-12.3.0-1/./gcc/ 
-B/home/ponyatov/player/host/i686-linux-uclibc/bin/ 
-B/home/ponyatov/player/host/i686-linux-uclibc/lib/ -isystem 
/home/ponyatov/player/host/i686-linux-uclibc/include -isystem 
/home/ponyatov/player/host/i686-linux-uclibc/sys-include -Wall 
-frelease -ffunction-sections -fdata-sections -O2 -g 
-fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields 
-nostdinc -I 
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime -I . 
-c 
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/exception.d -o core/exception.o

/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/sys/posix/sys/types.d:1227:40:
 error: undefined identifier '__SIZEOF_PTHREAD_MUTEX_T'
 1227 | byte[__SIZEOF_PTHREAD_MUTEX_T] __size;
  |^
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/sys/posix/sys/types.d:1175:39:
 error: undefined identifier '__SIZEOF_PTHREAD_ATTR_T'
 1175 | byte[__SIZEOF_PTHREAD_ATTR_T] __size;
  |   ^
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/sys/posix/sys/types.d:1192:39:
 error: undefined identifier '__SIZEOF_PTHREAD_COND_T'
 1192 | byte[__SIZEOF_PTHREAD_COND_T] __size;
  |   ^
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/sys/posix/sys/types.d:1198:43:
 error: undefined identifier '__SIZEOF_PTHREAD_CONDATTR_T'
 1198 | byte[__SIZEOF_PTHREAD_CONDATTR_T] __size;
  |   ^
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/sys/posix/sys/types.d:1233:44:
 error: undefined identifier '__SIZEOF_PTHREAD_MUTEXATTR_T'
 1233 | byte[__SIZEOF_PTHREAD_MUTEXATTR_T] __size;
  |^
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/sys/posix/sys/types.d:1265:41:
 error: undefined identifier '__SIZEOF_PTHREAD_RWLOCK_T'
 1265 | byte[__SIZEOF_PTHREAD_RWLOCK_T] __size;
  | ^
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/sys/posix/sys/types.d:1271:45:
 error: undefined identifier '__SIZEOF_PTHREAD_RWLOCKATTR_T'
 1271 | byte[__SIZEOF_PTHREAD_RWLOCKATTR_T] __size;
  | ^
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/sys/posix/sys/types.d:1375:42:
 error: undefined identifier '__SIZEOF_PTHREAD_BARRIER_T'
 1375 | byte[__SIZEOF_PTHREAD_BARRIER_T] __size;
  |  ^
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/sys/posix/sys/types.d:1381:46:
 error: undefined identifier '__SIZEOF_PTHREAD_BARRIERATTR_T'
 1381 | byte[__SIZEOF_PTHREAD_BARRIERATTR_T] __size;
  |  ^
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/internal/array/capacity.d:64:37:
 error: template instance 'core.internal.array.utils._d_HookTraceImpl!(char[], 
_d_arraysetlengthT, "Cannot resize arrays if compiling without support for runtime 
type information!")' error instantiating
   64 | alias _d_arraysetlengthTTrace = 
_d_HookTraceImpl!(Tarr, _d_arraysetlengthT, errorMessage);

  | ^
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/demangle.d:226:17:
 note: instantiated from here: '_d_arraysetlengthTImpl!(char[], char)'
  226 | dst.length = minBufSize;
  | ^
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/demangle.d:2111:14:
 note: instantiated from here: 'Demangle!(NoHooks)'
 2111 | auto d = Demangle!()(buf, dst);
  |  ^
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/demangle.d:2087:16:
 error: template instance 
'core.demangle.Demangle!(PrependHooks).Demangle.doDemangle!(parseMangledName)' 
error instantiating
 2087 | return doDemangle!parseMangledName();
  |^
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/demangle.d:2172:26:
 note: instantiated from here: 'Demangle!(PrependHooks)'
 2172 | alias Remangle = Demangle!(PrependHooks);
  |  ^
/home/ponyatov/player/ref/gcc-12.3.0/libphobos/libdruntime/core/demangle.d:2156:16:
 error: template instance 'object.RTInfo!(Replacement)' error instantiating
 2156 | static struct Replacement
  |^
make[4]: *** [Makefile:2477: core/demangle.lo] Ошибка 1
make[4]: *** Ожидание завершения заданий…
make[4]: выход из каталога 
«/home/ponyatov/player/tmp/gcc-12.3.0-1/i686-linux-uclibc/libphobos/libdruntime»

```

Re: cross-GDC for tiny embedded Linux

[Dmitry Ponyatov via D.gnu]

You'll need at least gcc-9/gdc-9 to build gcc-13.


Version problem was fixed by building `gcc-12.3.0` with `gdc` 
enabled on local host, and using it for the whole build in place 
of system-provided `gcc` toolchain.


```Makefile
# version
GCC_VER  = 12.3.0
```
```Makefile
# tool
GDCH = /usr/local/bin/gdc-12
CCH  = /usr/local/bin/gcc-12
CXXH = /usr/local/bin/g++-12
```
```Makefile
GCC_HOST= GDC=$(GDCH) CC=$(CCH) CXX=$(CXXH)
```
```Makefile
CFG_GCCH = --prefix=/usr/local $(WITH_GCCLIBS) 
--enable-languages="c,c++,d" \
   --program-suffix="-12"
$(OPT_HOST)\

   $(GCC_DISABLE) $(GCC_ENABLE)
```
```Makefile
CFG_GCC1 = $(CFG_BINUTILS1)$(WITH_GCCLIBS) 
--enable-languages="c,c++,d" \
   --with-headers=$(ROOT)/usr/include
$(GCC_HOST)\

   $(GCC_DISABLE) $(GCC_ENABLE)
```

Re: cross-GDC for tiny embedded Linux

[Iain Buclaw via D.gnu]

On Saturday, 21 October 2023 at 23:13:57 UTC, Dmitry Ponyatov 
wrote:

```sh
gdc --version
```
```
gdc (Debian 8.3.0-6) 8.3.0
```


You'll need at least gcc-9/gdc-9 to build gcc-13.

Re: cross-GDC for tiny embedded Linux

[Dmitry Ponyatov via D.gnu]

```sh
gdc --version
```
```
gdc (Debian 8.3.0-6) 8.3.0
```

cross-GDC for tiny embedded Linux

[Dmitry Ponyatov via D.gnu]

I'm trying to build a tiny Linux system with cross-compiling GDB:

https://github.com/ponyatov/player/blob/shadow/Makefile

```
BINUTILS_VER = 2.41
GCC_VER  = 13.2.0
```
```sh
cat /etc/os-release
```
```
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;
```
```sh
gdb --version
```
```
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
```

I've got this error:

```
/home/ponyatov/player/ref/gcc-13.2.0/gcc/d/dmd/root/file.d: In 
function ‘read’:
/home/ponyatov/player/ref/gcc-13.2.0/gcc/d/dmd/root/file.d:81:5: 
error: exception handling disabled, use -fexceptions to enable

```

It looks like my local host `gdb` has too old version.
Or maybe is there some another problem in `dmd` frontend on the 
modern `gcc13` distro?

Re: a mysterious linking error introduced by import a library

[Iain Buclaw via D.gnu]

On Saturday, 14 October 2023 at 19:28:59 UTC, Johann wrote:

On Saturday, 14 October 2023 at 19:01:53 UTC, Iain Buclaw wrote:

On Saturday, 14 October 2023 at 17:53:01 UTC, Johann wrote:
I cannot figure out this error is caused by `squiz_box` 
libray, `gdc` or `dub`. My apologies to you if I should have 
filed this bug in other places. Thanks for your attention.


Based on the symbol names, it could be this PR, which was 
fixed as of gdc versions 13.2 and 12.3


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108055


Sorry somehow I forget to attach the version of `gdc` in the 
post,


```bash
gdc --version
gdc (GCC) 13.2.1 20230918 (Red Hat 13.2.1-3)

cat /etc/redhat-release
Fedora release 39 (Thirty Nine)
```


Thanks.

One potential reduction seems to suggest gdc is emitting too 
much, rather than too little.


dmd 2.103.1
```
--- dmd -v
function  D main
function  app._d_cmain!().main
function  curl.get!().get
function  std.format.format!().format
function  std.format.formattedWrite!string.formattedWrite
function  
std.format.internal.write.formatValueImpl!int.formatValueImpl

--- nm app.o
W _Dmain
W main
W _D4curl__T3getZQfFNaNbAxaZv
W _D3std6format__TQkZQnFNaNbAyaQdZQg
W _D3std6format__T14formattedWriteTAyaZQvFNaNbQlZk
W _D3std6format8internal5write__T15formatValueImplTiZQuFNaNfxiZv
U _D3std6format8internal5write__T8getWidthTAyaZQoFNaNfQlZl
```


gdc 13.2
```
--- gdc -v
function  D main
function  app._d_cmain!().main
function  curl.get!().get
function  std.format.format!().format
function  std.format.formattedWrite!string.formattedWrite
function  
std.format.internal.write.formatValueImpl!int.formatValueImpl

function  std.format.internal.write.getWidth!string.getWidth
--- nm app.o
T _Dmain
T main
W _D4curl__T3getZQfFNaNbAxaZv
W _D3std6format__TQkZQnFNaNbAyaQdZQg
W _D3std6format__T14formattedWriteTAyaZQvFNaNbQlZk
W _D3std6format8internal5write__T15formatValueImplTiZQuFNaNfxiZv
W _D3std6format8internal5write__T8getWidthTAyaZQoFNaNfQlZl
U 
_D3std9algorithm9searching__T3allSQBg6format8internal5write__T8getWidthTAyaZQoFQhZ9__lambda2Z__TQCpTQBcZQCxMFNaNfQBpZb

```

Re: a mysterious linking error introduced by import a library

[Johann via D.gnu]

On Saturday, 14 October 2023 at 19:01:53 UTC, Iain Buclaw wrote:

On Saturday, 14 October 2023 at 17:53:01 UTC, Johann wrote:
I cannot figure out this error is caused by `squiz_box` 
libray, `gdc` or `dub`. My apologies to you if I should have 
filed this bug in other places. Thanks for your attention.


Based on the symbol names, it could be this PR, which was fixed 
as of gdc versions 13.2 and 12.3


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108055


Sorry somehow I forget to attach the version of `gdc` in the post,

```bash
gdc --version
gdc (GCC) 13.2.1 20230918 (Red Hat 13.2.1-3)

cat /etc/redhat-release
Fedora release 39 (Thirty Nine)
```

Re: a mysterious linking error introduced by import a library

[Iain Buclaw via D.gnu]

On Saturday, 14 October 2023 at 17:53:01 UTC, Johann wrote:
I cannot figure out this error is caused by `squiz_box` libray, 
`gdc` or `dub`. My apologies to you if I should have filed this 
bug in other places. Thanks for your attention.


Based on the symbol names, it could be this PR, which was fixed 
as of gdc versions 13.2 and 12.3


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108055

Re: a mysterious linking error introduced by import a library

[Johann via D.gnu]

On Saturday, 14 October 2023 at 18:15:11 UTC, Richard (Rikki) 
Andrew Cattermole wrote:
The frontend will attempt to not emit all template 
instantiations if it thinks that the instantiation isn't used. 
However it sometimes get this wrong, so you have to override it 
and tell it to emit them all anyway and let the linker do the 
eliding instead.


This is a known problem of all the compilers since its done by 
the shared frontend, rather than the glue layer.


It is a bug, but given how complex and time consuming it can be 
to minimize it to a small reproducible example, its not always 
worth the time to try and report it.


Thanks again for your lucid explanation. I will save 
`-fall-instantiations` flag in my main memory.

Re: a mysterious linking error introduced by import a library

[Richard (Rikki) Andrew Cattermole via D.gnu]

The frontend will attempt to not emit all template instantiations if it 
thinks that the instantiation isn't used. However it sometimes get this 
wrong, so you have to override it and tell it to emit them all anyway 
and let the linker do the eliding instead.


This is a known problem of all the compilers since its done by the 
shared frontend, rather than the glue layer.


It is a bug, but given how complex and time consuming it can be to 
minimize it to a small reproducible example, its not always worth the 
time to try and report it.

Re: a mysterious linking error introduced by import a library

[Johann via D.gnu]

On Saturday, 14 October 2023 at 17:58:27 UTC, Richard (Rikki) 
Andrew Cattermole wrote:

This may be a simple case of template emission eliding.

Did you try ``-fall-instantiations`` inside of a dflags 
directive?


Yeah, that works perfectly, thank you a lot.


This may be a simple case of template emission eliding.


So is this a bug in gdc? And what is a template emission eliding? 
I have never heard of it before.

Re: a mysterious linking error introduced by import a library

[Richard (Rikki) Andrew Cattermole via D.gnu]

This may be a simple case of template emission eliding.

Did you try ``-fall-instantiations`` inside of a dflags directive?

a mysterious linking error introduced by import a library

[Johann via D.gnu]

The following is a project created by `dub init`.

dub.json
```json
{
"authors": [
"john"
],
"dependencies": {
"squiz-box": {
"repository": 
"git+https://github.com/rtbo/squiz-box.git;,
"version": "6a10caaa01f7cefbe83c65b5a939bee2e0296250"
}
},
"description": "Demo program",
"license": "BSD 2 clause",
"name": "gdc_curl"
}
```

app.d
```d
import std.net.curl : get, download;

import squiz_box;

void main()
{
immutable jsonURL = "https://ziglang.org/download/index.json;;
auto jsonStr = get(jsonURL);
}
```

`squiz_box` is a dlang library for compression and decompression.

I am able to compile this `ldc2` and `dmd`, but not `gdc`. The 
error appears to be related to the line `import squiz_box`, 
removing of which causes the program to compile successfully, as 
the `main` function doesn't call the `squiz_box` library at all.


```bash
dub build --compiler=gdc --verbose

Using dub registry url 'https://code.dlang.org/'
Note: Failed to determine version of package gdc_curl at .. 
Assuming ~master.
  Version selection for dependency squiz-box (squiz-box) of 
gdc_curl is missing.

Scanning local packages...
Determined package version using GIT: squiz-box 
0.2.1+commit.51.ga962211
Determined package version using GIT: squiz-box 
0.2.1+commit.87.gf0ba9db
Determined package version using GIT: squiz-box 
0.3.0+commit.15.g6a10caa
  Found dependency squiz-box 
git+https://github.com/rtbo/squiz-box.git

Generating using build
Configuring dependent gdc_curl, deps:"squiz-box"
  Configuring dependent squiz-box, deps:
Starting Performing "debug" build using gdc for x86_64.
  Up-to-date squiz-box 0.3.0+commit.15.g6a10caa: target for 
configuration [library] is up to date.
Using existing build in 
/home/john/.dub/cache/squiz-box/0.3.0+commit.15.g6a10caa/build/library-debug-8Bi8iTVskbYwwEp3wicUsw.
Copying target from 
/home/john/.dub/cache/squiz-box/0.3.0+commit.15.g6a10caa/build/library-debug-8Bi8iTVskbYwwEp3wicUsw/libsquiz-box.a to /home/john/.dub/packages/squiz-box/6a10caaa01f7cefbe83c65b5a939bee2e0296250/squiz-box
Target 
'/home/john/.dub/cache/gdc_curl/~master/build/application-debug-G0CAYx5HyZ1UeOgA779Diw/gdc_curl' doesn't exist, need rebuild.
Building gdc_curl ~master: building configuration 
[application]

Using pkg-config to resolve library flags for liblzma, libzstd.
Using direct -l... flags for bz2.
gdc -o 
/home/john/.dub/cache/gdc_curl/~master/build/application-debug-G0CAYx5HyZ1UeOgA779Diw/gdc_curl -fdebug -g -Werror -Wall -fversion=Have_gdc_curl -fversion=Have_squiz_box -fversion=HaveSquizBzip2 -fversion=HaveSquizLzma -fversion=HaveSquizZstandard -Isource/ -I/home/john/.dub/packages/squiz-box/6a10caaa01f7cefbe83c65b5a939bee2e0296250/squiz-box/src/ source/app.d /home/john/.dub/cache/squiz-box/0.3.0+commit.15.g6a10caa/build/library-debug-8Bi8iTVskbYwwEp3wicUsw/libsquiz-box.a -lbz2 -Xlinker -llzma -Xlinker -lzstd
/usr/bin/ld: /tmp/ccPUp96p.o: in function 
`_D3std6format8internal5write__T8getWidthTAyaZQoFNaNfQlZl':

/usr/lib/gcc/x86_64-redhat-linux/13/include/d/std/format/internal/write.d:3639: 
undefined reference to 
`_D3std9algorithm9searching__T3allSQBg6format8internal5write__T8getWidthTAyaZQoFQhZ9__lambda2Z__TQCpTQBcZQCxMFNaNfQBpZb'
/usr/bin/ld: /tmp/ccPUp96p.o: in function 
`_D3std6format8internal5write__T20formatValueImplUlongTSQCb5array__T8AppenderTAyaZQoTaZQCdFNaNfKQBpmIbMKxSQDzQDy4spec__T10FormatSpecTaZQpZv':

/usr/lib/gcc/x86_64-redhat-linux/13/include/d/std/format/internal/write.d:262: 
undefined reference to 
`_D3std9algorithm9searching__T3allSQBg6format8internal5write__T20formatValueImplUlongTSQDg5array__T8AppenderTAyaZQoTaZQCdFKQBlmIbMKxSQFaQDu4spec__T10FormatSpecTaZQpZ10__lambda16Z__TQFvTAaZQGcMFNaNfQmZb'
/usr/bin/ld: 
/usr/lib/gcc/x86_64-redhat-linux/13/include/d/std/format/internal/write.d:268: undefined reference to `_D3std9algorithm9searching__T3allSQBg6format8internal5write__T20formatValueImplUlongTSQDg5array__T8AppenderTAyaZQoTaZQCdFKQBlmIbMKxSQFaQDu4spec__T10FormatSpecTaZQpZ10__lambda17Z__TQFvTAaZQGcMFNaNfQmZb'

collect2: error: ld returned 1 exit status
FAIL 
/home/john/.dub/cache/gdc_curl/~master/build/application-debug-G0CAYx5HyZ1UeOgA779Diw gdc_curl executable

Error gdc failed with exit code 1.
```

I cannot figure out this error is caused by `squiz_box` libray, 
`gdc` or `dub`. My apologies to you if I should have filed this 
bug in other places. Thanks for your attention.

Re: etc.c.sqlite3 missing from GDC phobos since gcc-12?

[Imperatorn via D.gnu]

On Friday, 11 August 2023 at 05:50:43 UTC, Joe Kappus wrote:
I noticed this yesterday when trying to package the dlang 
onedrive client in Gentoo with GDC 13.2 and it failed since it 
requires this.


It appears to have been removed when gdc became self-hosting in 
gcc during the gcc-12 release cycle.


There when it was present: 
https://github.com/gcc-mirror/gcc/tree/releases/gcc-11.2.0/libphobos/src/etc/c
Gone now: 
https://github.com/gcc-mirror/gcc/tree/releases/gcc-13.2.0/libphobos/src/etc/c
Still in dmd: 
https://github.com/dlang/phobos/blob/master/etc/c/sqlite3.d


I've asked in the #d IRC channel on Libera, and their guess was 
it was omitted by mistake so I'm writing in to verify: Would 
you know whether it's a bug and will return or otherwise why it 
got dropped? Thanks!


Hmm, is the plan that it should be on dub instead?

Re: GCC analyzer false positive

[Iain Buclaw via D.gnu]

On Thursday, 31 August 2023 at 13:53:55 UTC, Zachary Yedidia 
wrote:
The following code generates a warning when using GCC analyzer, 
but I don't think the warning is valid.


```
struct Guard {
~this() {}
}
Guard lock() {
return Guard();
}
void bar() {
auto foo = lock();
}
```

Compiled with GCC version 13.1:



I'm at the GNU Cauldron, and David has just said "don't use 
-fanalyzer on C++ in GCC 13, you will get rubbish out of it".  
This would also extend to all other languages that aren't C too.


The good news is that things are going to be improved in GCC 14.

Re: GCC analyzer false positive

[Iain Buclaw via D.gnu]

On Thursday, 31 August 2023 at 13:53:55 UTC, Zachary Yedidia 
wrote:
The following code generates a warning when using GCC analyzer, 
but I don't think the warning is valid.


```
struct Guard {
~this() {}
}
Guard lock() {
return Guard();
}
void bar() {
auto foo = lock();
}
```

Compiled with GCC version 13.1:

```
$ gdc -fanalyzer test.d -O2 -c
test.d: In function 'lock':
test.d:5:5: warning: use of uninitialized value 'MEM[(unsigned 
char * {ref-all})]' [CWE-457] 
[-Wanalyzer-use-of-uninitialized-value]

5 | return Guard();
  | ^
  'lock': events 1-2
|
|5 | return Guard();
|  | ^
|  | |
|  | (1) region created on stack here
|  | (2) use of uninitialized value 'MEM[(unsigned 
char * {ref-all})]' here

|
```

Any ideas? Thanks!


Hi,

Thanks for posting this!

Had a quick poke around - also with a C++ equivalent test - and 
it looks like GCC's static analyzer is not good at dealing with 
returning non-trivially copyable struct via NRVO.


I'll have a prod a bit more later, but my first instinct would be 
to raise a bug report with GCC.

GCC analyzer false positive

[Zachary Yedidia via D.gnu]

The following code generates a warning when using GCC analyzer, 
but I don't think the warning is valid.


```
struct Guard {
~this() {}
}
Guard lock() {
return Guard();
}
void bar() {
auto foo = lock();
}
```

Compiled with GCC version 13.1:

```
$ gdc -fanalyzer test.d -O2 -c
test.d: In function 'lock':
test.d:5:5: warning: use of uninitialized value 'MEM[(unsigned 
char * {ref-all})]' [CWE-457] 
[-Wanalyzer-use-of-uninitialized-value]

5 | return Guard();
  | ^
  'lock': events 1-2
|
|5 | return Guard();
|  | ^
|  | |
|  | (1) region created on stack here
|  | (2) use of uninitialized value 'MEM[(unsigned 
char * {ref-all})]' here

|
```

Any ideas? Thanks!

Re: GDC on CYGWIN available

[Ferhat Kurtulmuş via D.gnu]

On Tuesday, 22 August 2023 at 15:25:25 UTC, jicman wrote:
On Wednesday, 7 June 2023 at 18:04:43 UTC, Ferhat Kurtulmuş 
wrote:



[...]


Ok, maybe we can get this fixed, somehow. :-)

[...]


Not sure but there should be a config file similar to LDC's 
ldc2.conf but for GDC.

Re: GDC on CYGWIN available

[jicman via D.gnu]

On Wednesday, 7 June 2023 at 18:04:43 UTC, Ferhat Kurtulmuş wrote:

I ve been waiting for an answer for this question too. GDC has 
lack of windows support for ages.


Ok, maybe we can get this fixed, somehow. :-)

I installed GDC from cygwin's setup tool. If I run,

```
$ gdc -v
Using built-in specs.
COLLECT_GCC=gdc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/11/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with: 
/mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-11.4.0/configure 
--srcdir=/mnt/share/cygpkgs/gcc/gcc.x86_64/src/gcc-11.4.0 
--prefix=/usr --exec-prefix=/usr --localstatedir=/var 
--sysconfdir=/etc --docdir=/usr/share/doc/gcc 
--htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin 
--host=x86_64-pc-cygwin --target=x86_64-pc-cygwin 
--without-libiconv-prefix --without-libintl-prefix 
--libexecdir=/usr/lib --with-gcc-major-version-only 
--enable-shared --enable-shared-libgcc --enable-static 
--enable-version-specific-runtime-libs --enable-bootstrap 
--enable-__cxa_atexit --with-dwarf2 --with-tune=generic 
--enable-languages=ada,c,c++,d,fortran,lto,objc,obj-c++,jit 
--enable-graphite --enable-threads=posix --enable-libatomic 
--enable-libgomp --enable-libquadmath 
--enable-libquadmath-support --disable-libssp --enable-libada 
--disable-symvers --disable-multilib --with-gnu-ld --with-gnu-as 
--with-cloog-include=/usr/include/cloog-isl 
--without-libiconv-prefix --without-libintl-prefix 
--with-system-zlib --enable-linker-build-id 
--with-default-libstdcxx-abi=gcc4-compatible 
--enable-libstdcxx-filesystem-ts

Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (GCC)
```

you can see that it's install, but when I try to compile this 
very basic HelloWorld.d program,


```
$ cat HelloWorld.d
import std.stdio;
void main()
{
  writeln("Hello world");
}
```

I get these error:

```
$ gdc HelloWorld.d
d21: error: cannot find source code for runtime library file 
'object.d'
d21: note: dmd might not be correctly installed. Run 'dmd -man' 
for installation instructions.

d21: note: config file: not found
```

What do I need to do to get gdc to run in cygwin?

Is there a list of instructions on how to get this to work in any 
place?


It should be simple by copying certain files to the cygwin file 
structure. Thanks.

Re: gdc ice

[Iain Buclaw via D.gnu]

On Wednesday, 9 August 2023 at 12:51:51 UTC, Adam D Ruppe wrote:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110959


Related DMD bug - the backporting of which looks like it'd fix 
your test case too. https://issues.dlang.org/show_bug.cgi?id=23010

Re: gdc ice

[Adam D Ruppe via D.gnu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110959

Re: gdc ice

[Adam D Ruppe via D.gnu]

On Wednesday, 9 August 2023 at 12:44:16 UTC, Iain Buclaw wrote:

Can you raise a bug report against gcc.gnu.org/bugzilla?


yeah i just got the email approving the account a minute ago.

didn't take as long as i thought it would lol

Re: gdc ice

[Iain Buclaw via D.gnu]

On Wednesday, 9 August 2023 at 11:48:41 UTC, Adam D Ruppe wrote:

$ cat gdcbug.d
class ArsdExceptionBase : object.Exception {
package this(string operation, string file = __FILE__, 
size_t line = __LINE__, Throwable next = null) {

super(operation, file, line, next);
}
}

template ArsdException(alias Type, DataTuple...) {
static if(DataTuple.length)
alias Parent = ArsdException!(Type, DataTuple[0 
.. $-1]);

else
alias Parent = ArsdExceptionBase;

class ArsdException : Parent {
DataTuple data;

this(DataTuple data, string file = __FILE__, 
size_t line = __LINE__) {

this.data = data;
static if(is(Parent == 
ArsdExceptionBase))

super(null, file, line);
else
super(data[0 .. $-1], file, 
line);

}

static opCall(R...)(R r, string file = 
__FILE__, size_t line = __LINE__) {
return new ArsdException!(Type, 
DataTuple, R)(r, file, line);

}
}
}

/// This example shows how you can throw and catch the ad-hoc 
exception types.

void main() {
// 0 or 1 args works
try {
throw ArsdException!"Test"(1);
} catch(ArsdException!"Test" e) { // catch it without 
them

}

// 2 or more args causes ice
try {
throw ArsdException!"Test"(4, "four");
} catch(ArsdException!("Test", int, string) e) { // 
catch it and use info by specifying types
assert(e.data[0] == 4); // and extract 
arguments like this

assert(e.data[1] == "four");
}
}


Can you raise a bug report against gcc.gnu.org/bugzilla?

Only affects gdc-12.x - there's still time to fix before 12.4 is 
released.


```
==> gcc-9/gdc
arsd.d:19:38: error: constructor arsd.ArsdExceptionBase.this is 
not accessible from module arsd

   19 | super(null, file, line);
  |  ^
```

```
==> gcc-10//gdc
arsd.d:19:38: error: constructor arsd.ArsdExceptionBase.this is 
not accessible from module arsd

   19 | super(null, file, line);
  |  ^
```

```
==> gcc-11//gdc
arsd.d:34:43: error: template 
arsd.ArsdException!"Test".ArsdException.opCall cannot deduce 
function from argument types !()(int), candidates are:

   34 | throw ArsdException!"Test"(1);
  |   ^
```


```
==> gcc-12/gdc
arsd.d: In function ‘D main’:
arsd.d:40:23: internal compiler error: in layout_aggregate_type, 
at d/types.cc:574

   40 | throw ArsdException!"Test"(4, "four");
  |   ^
0x7d507f layout_aggregate_type
../../gcc/d/types.cc:574
...
```

```
==> gcc-13/gdc
OK!
```

```
==> gcc-mainline/gdc
OK!
```

gdc ice

[Adam D Ruppe via D.gnu]

$ gdc --version
gdc (GCC) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE.




$ gdc gdcbug.d
gdcbug.d: In function ‘D main’:
gdcbug.d:40:23: internal compiler error: in 
layout_aggregate_type, at d/types.cc:574

   40 | throw ArsdException!"Test"(4, "four");
  |   ^
0x1bb6f56 internal_error(char const*, ...)
???:0
0x7a967a fancy_abort(char const*, int, char const*)
???:0
0x9bcb03 TypeVisitor::visit(TypeClass*)
???:0
0x9bb8c2 build_ctype(Type*)
???:0
0x9bc056 TypeVisitor::visit(TypeFunction*)
???:0
0x9bb8c2 build_ctype(Type*)
???:0
0x99fa34 get_decl_tree(Declaration*)
???:0
0x9a7e0c ExprVisitor::visit(VarExp*)
???:0
0x9a3b0f build_expr(Expression*, bool, bool)
???:0
0x9a5b13 ExprVisitor::visit(CallExp*)
???:0
0x9a3b0f build_expr(Expression*, bool, bool)
???:0
0x9a3bab build_expr_dtor(Expression*)
???:0
0x9b0250 IRVisitor::visit(ThrowStatement*)
???:0
0x9b0bc8 IRVisitor::visit(ScopeStatement*)
???:0
0x9b08c8 IRVisitor::visit(TryCatchStatement*)
???:0
0x9b016f IRVisitor::visit(CompoundStatement*)
???:0
0x9b016f IRVisitor::visit(CompoundStatement*)
???:0
0x9af85e build_function_body(FuncDeclaration*)
???:0
0x9a320a DeclVisitor::visit(FuncDeclaration*)
???:0
0x99d7c6 build_decl_tree(Dsymbol*)
???:0
Please submit a full bug report, with preprocessed source (by 
using -freport-bug).

Please include the complete backtrace with any bug report.
See  for instructions.






$ cat gdcbug.d
class ArsdExceptionBase : object.Exception {
package this(string operation, string file = __FILE__, 
size_t line = __LINE__, Throwable next = null) {

super(operation, file, line, next);
}
}

template ArsdException(alias Type, DataTuple...) {
static if(DataTuple.length)
alias Parent = ArsdException!(Type, DataTuple[0 
.. $-1]);

else
alias Parent = ArsdExceptionBase;

class ArsdException : Parent {
DataTuple data;

this(DataTuple data, string file = __FILE__, 
size_t line = __LINE__) {

this.data = data;
static if(is(Parent == ArsdExceptionBase))
super(null, file, line);
else
super(data[0 .. $-1], file, line);
}

static opCall(R...)(R r, string file = __FILE__, 
size_t line = __LINE__) {
return new ArsdException!(Type, 
DataTuple, R)(r, file, line);

}
}
}

/// This example shows how you can throw and catch the ad-hoc 
exception types.

void main() {
// 0 or 1 args works
try {
throw ArsdException!"Test"(1);
} catch(ArsdException!"Test" e) { // catch it without them
}

// 2 or more args causes ice
try {
throw ArsdException!"Test"(4, "four");
} catch(ArsdException!("Test", int, string) e) { // catch 
it and use info by specifying types
assert(e.data[0] == 4); // and extract arguments 
like this

assert(e.data[1] == "four");
}
}

Re: ImportC automatic preprocessor?

[Iain Buclaw via D.gnu]

On Wednesday, 26 July 2023 at 04:35:43 UTC, Chris Piker wrote:
Is that a feature that is likely, or unlikely, to be added to a 
future version of GDC?




I expect it to be incremental.  There's a POC implementation that 
uses the built-in preprocessor that already exists in gdc 
(libcpp), initially none of the C-specific target macros would be 
exposed though - this is one arcane part of gcc/g++ that needs 
rewriting because at the moment using it just opens a [pandora's 
box](https://github.com/gcc-mirror/gcc/blob/31d18ff44244d1fe3ae913a5a1957d82059cb328/gcc/fortran/cpp.cc#L189-L200) (even in other front-end languages).

ImportC automatic preprocessor?

[Chris Piker via D.gnu]

Hi GDC

Over at: https://gcc.gnu.org/onlinedocs/gdc/Missing-Features.html 
I read that GDC doesn't invoke the preprocessor automatically:


```
ImportC Limitations

GNU D does not run the preprocessor automatically for any 
ImportC sources. Instead all C files are expected to be manually 
preprocessed before they are imported into the compilation.

```

Is that a feature that is likely, or unlikely, to be added to a 
future version of GDC?


Thanks,

Re: Can gdc --version or -dumpversion output the corresponding DMD front-end (language) version?

[Ernesto Castellotti via D.gnu]

On Tuesday, 11 July 2023 at 18:08:30 UTC, mw wrote:

Hi,

Currently,

```
$ gdc-12 --version
gdc-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0

$ gdc-12 -dumpversion
12
```

this is not very informative, as D (DMD) language is always 
changing, Can gdc --version or -dumpversion output the 
corresponding DMD front-end (language) version?


just as LDC does:

```
$ ldc2 --version
LDC - the LLVM D compiler (1.32.2):
  based on DMD v2.102.2 and LLVM 15.0.7

```


I don't think it's possible because --version and -dumpversion 
are common throughout GCC.


To get the version just compile a file with the content:
 pragma(msg, __VERSION__);

Can gdc --version or -dumpversion output the corresponding DMD front-end (language) version?

[mw via D.gnu]

Hi,

Currently,

```
$ gdc-12 --version
gdc-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0

$ gdc-12 -dumpversion
12
```

this is not very informative, as D (DMD) language is always 
changing, Can gdc --version or -dumpversion output the 
corresponding DMD front-end (language) version?


just as LDC does:

```
$ ldc2 --version
LDC - the LLVM D compiler (1.32.2):
  based on DMD v2.102.2 and LLVM 15.0.7

```

Re: Instruct gdc to look for standard library in another directory

[Johann via D.gnu]

On Saturday, 1 July 2023 at 16:53:10 UTC, Johann wrote:

On Saturday, 1 July 2023 at 15:36:55 UTC, Johann wrote:

On Saturday, 1 July 2023 at 10:18:43 UTC, Iain Buclaw wrote:
Is it too much to ask downstream package maintainers to 
politely use `/usr/share/dlang/{ldc,dmd}` ? :-)


Thanks for your help, Iain. I am going to report a bug to the 
distro maintainers then.


Meanwhile, I found out the problem can be worked around by 
using `-nostdinc` option.



```
-nostdinc
Do not search the standard system directories for D source 
and interface files.  Only the directories that have been 
specified with -I options (and the directory of the current 
file, if appropriate) are searched.

```


Problem is now fixed by ldc openSUSE package maintainer.

https://bugzilla.opensuse.org/show_bug.cgi?id=1212913

Re: Instruct gdc to look for standard library in another directory

[Johann via D.gnu]

On Saturday, 1 July 2023 at 15:36:55 UTC, Johann wrote:

On Saturday, 1 July 2023 at 10:18:43 UTC, Iain Buclaw wrote:
Is it too much to ask downstream package maintainers to 
politely use `/usr/share/dlang/{ldc,dmd}` ? :-)


Thanks for your help, Iain. I am going to report a bug to the 
distro maintainers then.


Meanwhile, I found out the problem can be worked around by using 
`-nostdinc` option.



```
-nostdinc
Do not search the standard system directories for D source 
and interface files.  Only the directories that have been 
specified with -I options (and the directory of the current file, 
if appropriate) are searched.

```

Re: Instruct gdc to look for standard library in another directory

[Johann via D.gnu]

On Saturday, 1 July 2023 at 10:18:43 UTC, Iain Buclaw wrote:
Is it too much to ask downstream package maintainers to 
politely use `/usr/share/dlang/{ldc,dmd}` ? :-)


Thanks for your help, Iain. I am going to report a bug to the 
distro maintainers then.

Re: Instruct gdc to look for standard library in another directory

[Iain Buclaw via D.gnu]

On Saturday, 1 July 2023 at 06:53:02 UTC, Johann wrote:
I have both `ldc` and `gdc` install on my OpenSUSE tumbleweed 
machine.


` Without `ldc-runtime-devel`, `gdc` is able to compile
successfully.


[--snip--]



How may I fix it? I tried to use "-I" and "-B" option, but to 
no avail.


Looks like ldc [might be too 
old](https://packagehub.suse.com/packages/ldc/1_29_0-bp155_3_26/)?


Regardless, I'd ask the package maintainers why they are putting 
compiler-dependent sources in /usr/include/d.


Actually, just any D sources in `/usr/include` has always seemed 
dubious to me.


i.e: On my system...

- Ada "includes" are installed into `/usr/share/ada/adainclude`
- Go "includes" are installed into `/usr/share/gocode/src`
- Rust "includes" are installed into `/usr/share/cargo/registry`
- Haskell "includes" are installed into 
`/usr/lib/haskell-packages`

- Ocaml "includes" are installed into `/usr/lib/ocaml`

Is it too much to ask downstream package maintainers to politely 
use `/usr/share/dlang/{ldc,dmd}` ? :-)

Re: Regression - quality of generated x86-64 code between GDC v12.3 and v13.1

[Iain Buclaw via D.gnu]

On Thursday, 8 June 2023 at 11:39:38 UTC, Iain Buclaw wrote:

On Thursday, 8 June 2023 at 04:13:30 UTC, Cecil Ward wrote:
I wrote a very small procedure in D and the x86-64 asm code 
generated in GDC 12.3 was excellent whereas that from 13.1 was 
insanely bloated, totally different. Note: the badness is 
independent of the -On optimisation level (-O3 used initially.)




So you're saying that a 4-int struct is not being treated as 
equivalent to an `int[4]`?


https://d.godbolt.org/z/G77fW48xG

If possible, a bug report would be great on this.


Fix has been committed to mainline and gcc-13.

https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=f2eeda5652438fe783d4e3878139481a1b8606b6;hp=09124b7ed7709721e86556b4083ef40925d7489b

Instruct gdc to look for standard library in another directory

[Johann via D.gnu]

I have both `ldc` and `gdc` install on my OpenSUSE tumbleweed 
machine.


Without `ldc-runtime-devel`, `gdc` is able to compile 
successfully.

```bash
binary/usr/lib64/gcc/x86_64-suse-linux/13/d21
version   v2.103.0-rc.1

predefs   GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions 
GNU_StackGrowsDown GNU_InlineAsm D_LP64 assert D_PreConditions 
D_PostConditions D_Invariants D_ModuleInfo D_Exceptions 
D_TypeInfo all X86_64 D_HardFloat Posix linux CRuntime_Glibc 
CppRuntime_Gcc

parse app
importall app
import
object	(/usr/lib64/gcc/x86_64-suse-linux/13/include/d/object.d)



... rest omitted
```

However, after installing `ldc-runtime-devel`, gdc fails to 
compile a "hello world" because it tries to use the phobos 
library provided by ldc.


gdc installs its library at 
`/usr/lib64/gcc/x86_64-suse-linux/13/include/d/`

ldc installs its library at `/usr/include/d`

`gdc -v source/app.d` shows,


```bash
gcc version 13.1.1 20230522 [revision 
dd36656ada05731c069ecd5b1878380294fb1f3e] (SUSE Linux)
COLLECT_GCC_OPTIONS='-v' '-o' 'a.out' '-shared-libgcc' 
'-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
 /usr/lib64/gcc/x86_64-suse-linux/13/d21 source/app.d -quiet 
-dumpdir a- -dumpbase app.d -dumpbase-ext .d -mtune=generic 
-march=x86-64 -version -v -o /tmp/ccFpibdu.s
GNU D (SUSE Linux) version 13.1.1 20230522 [revision 
dd36656ada05731c069ecd5b1878380294fb1f3e] (x86_64-suse-linux)
	compiled by GNU C version 13.1.1 20230522 [revision 
dd36656ada05731c069ecd5b1878380294fb1f3e], GMP version 6.2.1, 
MPFR version 4.2.0-p9, MPC version 1.3.1, isl version isl-0.26-GMP


GGC heuristics: --param ggc-min-expand=100 --param 
ggc-min-heapsize=131072

binary/usr/lib64/gcc/x86_64-suse-linux/13/d21
version   v2.103.0-rc.1

predefs   GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions 
GNU_StackGrowsDown GNU_InlineAsm D_LP64 assert D_PreConditions 
D_PostConditions D_Invariants D_ModuleInfo D_Exceptions 
D_TypeInfo all X86_64 D_HardFloat Posix linux CRuntime_Glibc 
CppRuntime_Gcc

parse app
importall app
importobject(/usr/include/d/object.d)
importcore.attribute(/usr/include/d/core/attribute.d)
import
gcc.attributes	(/usr/lib64/gcc/x86_64-suse-linux/13/include/d/gcc/attributes.d)

importcore.internal.hash(/usr/include/d/core/internal/hash.d)
import
core.internal.traits	(/usr/include/d/core/internal/traits.d)
import
core.internal.entrypoint	(/usr/include/d/core/internal/entrypoint.d)
import
core.internal.array.appending	(/usr/include/d/core/internal/array/appending.d)
import
core.internal.array.comparison	(/usr/include/d/core/internal/array/comparison.d)
import
core.internal.array.equality	(/usr/include/d/core/internal/array/equality.d)
import
core.internal.array.casting	(/usr/include/d/core/internal/array/casting.d)
import
core.internal.array.concatenation	(/usr/include/d/core/internal/array/concatenation.d)
import
core.internal.array.construction	(/usr/include/d/core/internal/array/construction.d)
import
core.internal.array.arrayassign	(/usr/include/d/core/internal/array/arrayassign.d)
import
core.internal.array.capacity	(/usr/include/d/core/internal/array/capacity.d)
import
core.internal.dassert	(/usr/include/d/core/internal/dassert.d)

importcore.atomic   (/usr/include/d/core/atomic.d)
import
core.internal.attributes	(/usr/include/d/core/internal/attributes.d)
import
core.internal.atomic	(/usr/include/d/core/internal/atomic.d)
import
gcc.builtins	(/usr/lib64/gcc/x86_64-suse-linux/13/include/d/gcc/builtins.d)
import
gcc.config	(/usr/lib64/gcc/x86_64-suse-linux/13/include/d/gcc/config.d)
import
core.internal.destruction	(/usr/include/d/core/internal/destruction.d)
import
core.internal.moving	(/usr/include/d/core/internal/moving.d)
import
core.internal.postblit	(/usr/include/d/core/internal/postblit.d)
import
core.internal.switch_	(/usr/include/d/core/internal/switch_.d)

importcore.lifetime (/usr/include/d/core/lifetime.d)
importcore.builtins (/usr/include/d/core/builtins.d)
importstd.stdio (/usr/include/d/std/stdio.d)
importcore.stdc.stddef  (/usr/include/d/core/stdc/stddef.d)
import
std.algorithm.mutation	(/usr/include/d/std/algorithm/mutation.d)

importstd.traits(/usr/include/d/std/traits.d)
importstd.meta  (/usr/include/d/std/meta.d)
import
std.range.primitives	(/usr/include/d/std/range/primitives.d)

importstd.typecons  (/usr/include/d/std/typecons.d)
importstd.format.spec   (/usr/include/d/std/format/spec.d)
importstd.format.write  (/usr/include/d/std/format/write.d)
import
std.format.internal.write	(/usr/include/d/std/format/internal/write.d)
import
std.internal.attributes	(/usr/include/d/std/internal/attributes.d)

importstd.range (/usr/include/d/std/range/package.d)
importstd.array (/usr/include/d/std/array.d)
importstd.functional(/usr/include/d/std/functional.d)
importstd.conv   

Re: GDC for ARM MacOS / OSX

[Cecil Ward via D.gnu]

On Thursday, 29 June 2023 at 09:18:19 UTC, Iain Buclaw wrote:

On Thursday, 29 June 2023 at 05:27:57 UTC, Cecil Ward wrote:
I tried getting GCC on my ARM M2 Mac using the homebrew 
package manager, which is how I got LDC. It gave me C++ and C 
and FORTRAN, but no sign of any GDC.


How is GCC available when it has no support for 
aarch64-darwin2x?


(Experimental support is available in [iains fork on 
github](https://github.com/iains/gcc-darwin-arm64) targeting 
the 14.x development branch)


Iain and I have been going through arm64-darwin support in D 
run-time, mostly it's just getting cross bootstrap from gcc-11 
done cleanly.  Nothing that I expect to be made concretely 
available just yet, though I am hoping that GCC will finally 
get support for M1/M2 by the time 14.1 is released in May 
though.


Thankyou for your good work Iain. I don’t have a working GDC as 
the one on my Raspberry Pi AAarch64 Debian Buster dies with an 
error message ever time you try to compile. I have run GDC on 
32-bit ARM on the Raspberry Pi and in godbolt.org on x86-64.


I will get hold of an x86-64 box with Linux on it. Get round the 
problems that way.

Re: GDC for ARM MacOS / OSX

[Iain Buclaw via D.gnu]

On Thursday, 29 June 2023 at 05:27:57 UTC, Cecil Ward wrote:
I tried getting GCC on my ARM M2 Mac using the homebrew package 
manager, which is how I got LDC. It gave me C++ and C and 
FORTRAN, but no sign of any GDC.


How is GCC available when it has no support for aarch64-darwin2x?

(Experimental support is available in [iains fork on 
github](https://github.com/iains/gcc-darwin-arm64) targeting the 
14.x development branch)


Iain and I have been going through arm64-darwin support in D 
run-time, mostly it's just getting cross bootstrap from gcc-11 
done cleanly.  Nothing that I expect to be made concretely 
available just yet, though I am hoping that GCC will finally get 
support for M1/M2 by the time 14.1 is released in May though.

GDC for ARM MacOS / OSX

[Cecil Ward via D.gnu]

I tried getting GCC on my ARM M2 Mac using the homebrew package 
manager, which is how I got LDC. It gave me C++ and C and 
FORTRAN, but no sign of any GDC.

Re: bug report x86-64 code: je / jbe

[Iain Buclaw via D.gnu]

On Monday, 19 June 2023 at 09:54:32 UTC, Iain Buclaw wrote:

On Sunday, 18 June 2023 at 02:55:32 UTC, Cecil Ward wrote:

On Friday, 16 June 2023 at 13:12:06 UTC, Iain Buclaw wrote:


Redundant jump? Yes, arguably. Leads to wrong runtime? 
Doesn't look that way.


Completely agree with Iain, it’s not incorrect code, I wasn’t 
intending to suggest that. I’d just say suboptimal, and not 
the very best code generation possible.


By the way, I suspect it's related to this problem report.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96435



Fix has been committed in time for 13.2 release.

Re: bug report x86-64 code: je / jbe

[Iain Buclaw via D.gnu]

On Sunday, 18 June 2023 at 02:55:32 UTC, Cecil Ward wrote:

On Friday, 16 June 2023 at 13:12:06 UTC, Iain Buclaw wrote:


Redundant jump? Yes, arguably. Leads to wrong runtime? Doesn't 
look that way.


Completely agree with Iain, it’s not incorrect code, I wasn’t 
intending to suggest that. I’d just say suboptimal, and not the 
very best code generation possible.


By the way, I suspect it's related to this problem report.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96435

Taken from upstream DMD comment (I suspect is still not fixed in 
either DMD, possibly LDC too but haven't checked).


https://issues.dlang.org/show_bug.cgi?id=20148#c3

Essentially, every read of a boolean gets turned into 
`(*(ubyte*)) & 1`.


This *could* be limited to `@safe` code, or just accessing field 
members of a union I suppose.

Re: bug report x86-64 code: je / jbe

[Cecil Ward via D.gnu]

On Friday, 16 June 2023 at 13:12:06 UTC, Iain Buclaw wrote:

On Wednesday, 14 June 2023 at 12:35:43 UTC, Cecil Ward wrote:
I have just noticed a bug in the latest release of GDC that 
targets x86-64. For example GDC 12.3 and above versions too, 
running on X86-64, targeting self. This was built with:

 -O3 -frelease -march=alderlake



What leads you to believe that it is buggy?


Generated code is:

   je L1
   jbe L1



What I see is the first instruction is going to relate to this 
condition.



if ( unlikely( p == 1 ) ) return x;


Then the next instruction is the condition in the following 
for-loop.



for ( exp_ui_t i = p; i > 1; i >>= 1 )


Redundant jump? Yes, arguably. Leads to wrong runtime? Doesn't 
look that way.


Completely agree with Iain, it’s not incorrect code, I wasn’t 
intending to suggest that. I’d just say suboptimal, and not the 
very best code generation possible.

Re: bug report x86-64 code: je / jbe

[Iain Buclaw via D.gnu]

On Wednesday, 14 June 2023 at 12:35:43 UTC, Cecil Ward wrote:
I have just noticed a bug in the latest release of GDC that 
targets x86-64. For example GDC 12.3 and above versions too, 
running on X86-64, targeting self. This was built with:

 -O3 -frelease -march=alderlake



What leads you to believe that it is buggy?


Generated code is:

   je L1
   jbe L1



What I see is the first instruction is going to relate to this 
condition.



if ( unlikely( p == 1 ) ) return x;


Then the next instruction is the condition in the following 
for-loop.



for ( exp_ui_t i = p; i > 1; i >>= 1 )


Redundant jump? Yes, arguably. Leads to wrong runtime? Doesn't 
look that way.

bug report x86-64 code: je / jbe

[Cecil Ward via D.gnu]

I have just noticed a bug in the latest release of GDC that 
targets x86-64. For example GDC 12.3 and above versions too, 
running on X86-64, targeting self. This was built with:

 -O3 -frelease -march=alderlake

Generated code is:

   je L1
   jbe L1

…
…
L1:  ret

The probably reason for this is my use of the GDC built in for 
indicating whether conditional jumps are likely or unlikely to be 
taken. I wrote a trivial routine likely() and unlikely() and used 
this as follows:


public
T pow(T, exp_ui_t )( in T x, in exp_ui_t p ) pure @safe nothrow 
@nogc

if ( is ( exp_ui_t == ulong ) || is ( exp_ui_t == uint ) )
in  {
static assert( is ( typeof( x * x ) ) );
assert( p >= 0 );
}
out ( ret ) {
assert( ( p == 0 && ret == 1 ) || !( p == 0 ) );
}
do
{
if ( unlikely( p == 0 ) ) return 1;
if ( unlikely( p == 1 ) ) return x;

/*
if ( unlikely( x == 0 ) )   // fast-path opt, unnecessary
return x;
if ( unlikely( x == 1 ) )   // fast-path opt, unnecessary
return x;
*/

T s = x;
T v = 1;

for ( exp_ui_t i = p; i > 1; i >>= 1 )
{
v = ( i & 0x1 ) ? s * v : v;
s = s * s;
}
   //assert( p > 1 && pow( x, p ) == ( p > 1 ? x * pow( x, p-1) : 
1) );

return v * s;
}

pragma( inline, true )
private
bool builtin_expect()( in bool test_cond, in bool expected_cond ) 
 pure nothrow @safe @nogc

{
version ( LDC )
	{// ldc.intrinsics.llvm_expect - didi not seem to work when 
tested in LDC 1.22

import ldc.intrinsics : llvm_expect;
return cast(bool) llvm_expect( test_cond, expected_cond );
}
version ( GDC )
{
import gcc.builtins : __builtin_expect;
	return cast(bool) __builtin_expect( test_cond, expected_cond 
);

}
return test_cond;
}


pragma( inline, true )
public
bool likely()( in bool test_cond ) pure nothrow @safe @nogc
/* Returns test_cond which makes it convenient to do assert( 
unlikely() )
 * Also emulates builtin_expect's return behaviour, by returning 
the argument

 */ {
return builtin_expect( test_cond, true );
}


pragma( inline, true )
public
bool unlikely()( in bool test_cond ) pure nothrow @safe @nogc
/* Returns test_cond which makes it convenient to do assert( 
unlikely() )
 * Also emulates builtin_expect's return behaviour, by returning 
the argument

 */
{
return builtin_expect( test_cond, false );
}
// ~~~ module likely - end.



This is not the whole of this .d file, I can of course give you 
the whole lot if you desire. I inspected the result in Matt 
Godbolt’s compiler explorer website godbolt.org.


An aside: LDC:: I need to look at LDC’s llvm_expect to see if it 
is controlling the branches the way I wish. Does anyone know if 
llvm_expect has any problems?

Re: Regression - quality of generated x86-64 code between GDC v12.3 and v13.1

[Iain Buclaw via D.gnu]

On Thursday, 8 June 2023 at 04:13:30 UTC, Cecil Ward wrote:
I wrote a very small procedure in D and the x86-64 asm code 
generated in GDC 12.3 was excellent whereas that from 13.1 was 
insanely bloated, totally different. Note: the badness is 
independent of the -On optimisation level (-O3 used initially.)




So you're saying that a 4-int struct is not being treated as 
equivalent to an `int[4]`?


https://d.godbolt.org/z/G77fW48xG

If possible, a bug report would be great on this.

Thanks.

Regression - quality of generated x86-64 code between GDC v12.3 and v13.1

[Cecil Ward via D.gnu]

I wrote a very small procedure in D and the x86-64 asm code 
generated in GDC 12.3 was excellent whereas that from 13.1 was 
insanely bloated, totally different. Note: the badness is 
independent of the -On optimisation level (-O3 used initially.)


Here’s the D code and following it, two asm code snippets:





public
pragma( inline, true )
cpuid_abcd_t
cpuid_insn( in uint32_t eax ) pure nothrow @nogc @trusted
{ /* ecx arg omitted; absolutely minimal variant wrapper */
   	assert( ! is_ecx_needed( eax ) );	// since we are not 
providing an ecx, we had better not be needing to supply one


static assert( eax.sizeof * 8 == 32 );  // optional, exact
static assert( eax.sizeof * 8 >= 32 );   // essential min

   	const uint32_t in_eax = eax;	// really just for 
type-checking, and constness-assertion

static assert( in_eax.sizeof * 8 == 32 );

	cpuid_abcd_t ret = void;	/* undefined until the cpuid insn 
writes it */
	static assert(ret.eax.sizeof * 8 == 32 && ret.ebx.sizeof * 8 
== 32
   	   && ret.ecx.sizeof * 8 == 32 && ret.edx.sizeof 
* 8 == 32 );

asm pure nothrow @nogc
{
".intel_syntax   " ~ "\n\t" ~

"cpuid"  ~ "\n\t" ~

".att_syntax \n"

	: /* outputs : it is guaranteed that all bits 63…32 of 
rax/rbx/rcx/rdx etc are zeroed in output. */
		"=a" ( ret.eax ),	// an lhs ref, write-only; and only bits 
31…0 are significant

"=b" ( ret.ebx ), // ..  ..
"=c" ( ret.ecx ),
"=d" ( ret.edx )
:   /* inputs : */
"a"  ( in_eax )   // read.
	// /* no ecx input - this is the variant with input ecx 
omitted */

:   /* no clobbers apart from the outputs already listed */
	/* does cpuid set flags? - think not, so no "cc" clobber 
reqd */

;
}
return ret;
}

/*  */

GDC 12.3::  -O3 -frelease -march=native

pushrbx
mov eax, edi
cpuid
mov rsi, rdx
sal rbx, 32
mov eax, eax
mov edx, ecx
sal rsi, 32
or  rax, rbx
pop rbx
or  rdx, rsi
ret


GDC 13.1 = v. bad, same switches:  -O3 -frelease -march=native

pushbp
mov eax, edi
mov rbp, rsp
pushrbx
and rsp, -32
cpuid
vmovd   xmm3, eax
vmovd   xmm2, ecx
vpinsrd xmm1, xmm2, edx, 1
vpinsrd xmm0, xmm3, rbx, 1
vpunpcklqdq   xmm4, xmm0, xmm1
vmovdqa xmmword ptr [rsp-80], xmm4
mov rax, qword ptr [rsp-80]
mov rdx, qword ptr [rsp-72]
mov rbx, qword ptr [rbp-8]  
leave
ret
/*  */

Re: GDC on CYGWIN available

[Ferhat Kurtulmuş via D.gnu]

On Wednesday, 7 June 2023 at 17:47:06 UTC, jicman wrote:

On Tuesday, 6 June 2023 at 18:55:31 UTC, jicman wrote:

Greetings!

I was very happy to see GDC available on cygwin, but, the list 
said, "...and without a working runtime the next major release 
of gcc will again have to drop it as it would no longer 
bootstrap." Has a decision being made of not supporting 
cygwin? Thanks.


josé


Is anyone on this forum, or is everyone on vacation? :-)


I ve been waiting for an answer for this question too. GDC has 
lack of windows support for ages.

Re: GDC on CYGWIN available

[jicman via D.gnu]

On Tuesday, 6 June 2023 at 18:55:31 UTC, jicman wrote:

Greetings!

I was very happy to see GDC available on cygwin, but, the list 
said, "...and without a working runtime the next major release 
of gcc will again have to drop it as it would no longer 
bootstrap." Has a decision being made of not supporting cygwin? 
Thanks.


josé


Is anyone on this forum, or is everyone on vacation? :-)

GDC on CYGWIN available

[jicman via D.gnu]

Greetings!

I was very happy to see GDC available on cygwin, but, the list 
said, "...and without a working runtime the next major release of 
gcc will again have to drop it as it would no longer bootstrap." 
Has a decision being made of not supporting cygwin? Thanks.


josé

Re: GDMD picking up wrong GDC

[kinke via D.gnu]

On Sunday, 7 May 2023 at 13:41:43 UTC, WebFreak001 wrote:
I have multiple GDCs installed through apt, how do I make gdmd 
pick the higher one (`gdc-12`) and not just `gdc`?


With e.g. `ln -s gdmd /usr/bin/gdmd-12`, and then using 
`gdmd-12`. As shown by the few linked lines in the Perl script, 
the gdmd script invoked as `[prefix-][g]dmd[-suffix]` invokes a 
`[prefix-]gdc[-suffix]` in the same directory.

Re: GDMD picking up wrong GDC

[WebFreak001 via D.gnu]

On Thursday, 4 May 2023 at 14:58:48 UTC, Iain Buclaw wrote:

On Thursday, 4 May 2023 at 13:05:07 UTC, WebFreak001 wrote:
In GitHub Actions I installed `sudo apt install gdc-12` now 
inside Ubuntu 22.04, however `gdc` still seemed to be a small 
extra package that's symlinking gdc to gdc-11.


Now gdmd is picking up GDC 11 instead of GDC 12, causing 
issues in the build.


Is there a way to tell gdmd to use GDC 12? Right now I hacked 
around this by doing




I imagine what you're seeing is gdmd using the correct version 
of the compiler, just not the one you wanted.


https://github.com/D-Programming-GDC/gdmd/blob/master/dmd-script#L71-L76


I have multiple GDCs installed through apt, how do I make gdmd 
pick the higher one (`gdc-12`) and not just `gdc`?

Re: GDMD picking up wrong GDC

[Iain Buclaw via D.gnu]

On Thursday, 4 May 2023 at 13:05:07 UTC, WebFreak001 wrote:
In GitHub Actions I installed `sudo apt install gdc-12` now 
inside Ubuntu 22.04, however `gdc` still seemed to be a small 
extra package that's symlinking gdc to gdc-11.


Now gdmd is picking up GDC 11 instead of GDC 12, causing issues 
in the build.


Is there a way to tell gdmd to use GDC 12? Right now I hacked 
around this by doing




I imagine what you're seeing is gdmd using the correct version of 
the compiler, just not the one you wanted.


https://github.com/D-Programming-GDC/gdmd/blob/master/dmd-script#L71-L76

GDMD picking up wrong GDC

[WebFreak001 via D.gnu]

In GitHub Actions I installed `sudo apt install gdc-12` now 
inside Ubuntu 22.04, however `gdc` still seemed to be a small 
extra package that's symlinking gdc to gdc-11.


Now gdmd is picking up GDC 11 instead of GDC 12, causing issues 
in the build.


Is there a way to tell gdmd to use GDC 12? Right now I hacked 
around this by doing


```
sudo rm /usr/bin/gdc
sudo ln -s /usr/bin/gdc-12 /usr/bin/gdc
```

but if this wasn't a CI, I wouldn't really wanna do this.

Would it be possible to provide extra gdmd scripts like gdmd-12 
that pick gdc-12 on Ubuntu?


see commit 
https://github.com/dlang-community/libdparse/commit/03099519982c10b9d7831771bcb744f06b727400


Since this is manual DMD invocation, and not dub, I can't just 
specify gdc-12 as compiler.

D is cancer

[DIsCancer via D.gnu]

D is cancer

Re: Reducing debug info for stack traces, while preserving for gdb

[Iain Buclaw via D.gnu]

Hi,

On Wednesday, 14 December 2022 at 22:23:49 UTC, Witold Baryluk 
wrote:>
The bulk of information is in `.debug_info`. But I believe it 
contains way more information than is really needed to just 
produce line numbers.




You're observation is correct.  GDC uses libbacktrace to produce 
stack traces, and this indeed does traverse the `.debug_info` 
section in order to achieve its job.


https://github.com/gcc-mirror/gcc/blob/8ec139af5ea9657c7517c1483c7a577815bea48e/libbacktrace/dwarf.c#L2116-L2120





I did inspect final binaries , and it is using DWARF version 5.

I also tried `-gas-loc-support` , but no change.

Using `-g1` makes stack traces work nicely, by making 
`.debug_info` smaller, but then debugging in `gdb` is very 
limited. One option would be to compile application twice, once 
with `-g1` and once with `-g3`. But I really do not think this 
is supported, or reliable, even if I enable deterministic 
builds.




I'm not sure on this, I'd have to give it some thought.

In one article ( 
https://support.backtrace.io/hc/en-us/articles/360040105792-DWARF#RemovingDebugInformation )  I read that for C/C++ in GCC, it is enough to preserve only `.debug_frame` and `.debug_line` to get function, source filenames and line numbers. But that is not true for gdc and its stacktrace handler.




C++ stdlib doesn't give stack traces AFAIU, and if it does, it 
would be using libbacktrace too.  I guess then the article must 
be referring to the implementation of `execinfo.h` and/or 
`dladdr`.


Perhaps a run-time fallback could be added to gdc's stack trace 
support to use the `execinfo.h` backtrace functions if the 
`.debug_info` (or whatever platform equivalent) section does not 
exist.  From what I recall, execinfo is not quite as accurate as 
libbacktrace though.


Iain.

Re: GDC mainline (20221219) fails to build on OpenBSD (patch included)

[Brian Callahan via D.gnu]

On Tuesday, 20 December 2022 at 02:19:33 UTC, Iain Buclaw wrote:
On Monday, 19 December 2022 at 14:00:38 UTC, Brian Callahan 
wrote:

Hi Iain --

GDC mainline stopped building on OpenBSD recently. Below is 
the diff to fix things.


[...]


Thanks, better to send that to upstr dmd though (I did say they 
should've used @weak)


Ah. Thanks. I was on the dmd stable branch and didn't see it so I 
thought it was something GDC-specific.


~Brian

Re: GDC mainline (20221219) fails to build on OpenBSD (patch included)

[Iain Buclaw via D.gnu]

On Monday, 19 December 2022 at 14:00:38 UTC, Brian Callahan wrote:

Hi Iain --

GDC mainline stopped building on OpenBSD recently. Below is the 
diff to fix things.


[...]


Thanks, better to send that to upstr dmd though (I did say they 
should've used @weak)

GDC mainline (20221219) fails to build on OpenBSD (patch included)

[Brian Callahan via D.gnu]

Hi Iain --

GDC mainline stopped building on OpenBSD recently. Below is the 
diff to fix things.


Thanks.

~Brian

diff --git a/libphobos/libdruntime/core/demangle.d 
b/libphobos/libdruntime/core/demangle.d

index 869ade64821..30e38c76479 100644
--- a/libphobos/libdruntime/core/demangle.d
+++ b/libphobos/libdruntime/core/demangle.d
@@ -2929,6 +2929,7 @@ CXX_DEMANGLER getCXXDemangler() nothrow 
@trusted
 version (FreeBSD) import core.sys.freebsd.dlfcn : 
RTLD_DEFAULT;
 version (linux) import core.sys.linux.dlfcn : 
RTLD_DEFAULT;
 version (NetBSD) import core.sys.netbsd.dlfcn : 
RTLD_DEFAULT;
+version (OpenBSD) import core.sys.openbsd.dlfcn : 
RTLD_DEFAULT;
 version (OSX) import core.sys.darwin.dlfcn : 
RTLD_DEFAULT;
 version (Solaris) import core.sys.solaris.dlfcn : 
RTLD_DEFAULT;

Re: Reducing debug info for stack traces, while preserving for gdb

[Witold Baryluk via D.gnu]

For example to give you some context.

This is an example small app, the actual app is significantly 
larger (binary with debug symbols is about 20MB, without debug 
symbols only 2-3MB).


```
$ ~/bloaty/build/bloaty binary-O3-g-g3-gz  # (original binary)
FILE SIZEVM SIZE
 --  --
  19.8%   107Ki  39.3%   107Ki.text
  17.0%  93.0Ki   0.0%   0.strtab
  13.3%  72.4Ki   0.0%   0.debug_info   # 
72kB

  12.0%  65.3Ki  23.8%  65.3Ki.dynstr
   5.2%  28.5Ki  10.4%  28.5Ki.rodata
   5.1%  27.9Ki  10.2%  27.9Ki.eh_frame
   5.0%  27.5Ki   0.0%   0.debug_loclists   # 
27kB

   4.5%  24.8Ki   0.0%   0.symtab
   3.7%  20.4Ki   0.0%   0.debug_str# 
20kB
   3.4%  18.5Ki   0.0%   0.debug_line   # 
18.5kB

   3.2%  17.6Ki   6.4%  17.6Ki.dynsym
   1.3%  7.25Ki   0.0%   0[Unmapped]
   1.2%  6.61Ki   2.1%  5.64Ki[27 Others]
   1.1%  6.18Ki   2.3%  6.18Ki.eh_frame_hdr
   0.9%  5.08Ki   1.9%  5.08Ki.gnu.hash
   0.8%  4.31Ki   1.6%  4.31Ki.data.rel.ro
   0.8%  4.12Ki   1.5%  4.12Ki.rela.dyn
   0.5%  2.69Ki   0.0%   0[ELF Section Headers]
   0.4%  2.38Ki   0.0%   0.debug_rnglists   # 
small
   0.3%  1.74Ki   0.0%   0.debug_abbrev # 
small

   0.3%  1.52Ki   0.6%  1.52Ki.rela.plt
 100.0%   545Ki 100.0%   273KiTOTAL
```


```
$ ~/bloaty/build/bloaty binary-O3-g-g1-gz # binary with -g1, and 
compressed debug sections

FILE SIZEVM SIZE
 --  --
  24.4%   107Ki  39.3%   107Ki.text
  21.1%  93.0Ki   0.0%   0.strtab
  14.8%  65.3Ki  23.8%  65.3Ki.dynstr
   6.5%  28.5Ki  10.4%  28.5Ki.rodata
   6.3%  27.9Ki  10.2%  27.9Ki.eh_frame
   5.6%  24.8Ki   0.0%   0.symtab
   4.0%  17.6Ki   6.4%  17.6Ki.dynsym
   3.5%  15.5Ki   0.0%   0.debug_line  # 
smaller
   2.8%  12.2Ki   0.0%   0.debug_str   # 
smaller
   2.4%  10.4Ki   0.0%   0.debug_info  # way 
smaller

   1.6%  7.25Ki   0.0%   0[Unmapped]
   1.4%  6.18Ki   2.3%  6.18Ki.eh_frame_hdr
   1.2%  5.08Ki   1.9%  5.08Ki.gnu.hash
   1.0%  4.31Ki   1.6%  4.31Ki.data.rel.ro
   1.0%  4.20Ki   0.9%  2.43Ki[25 Others]
   0.9%  4.12Ki   1.5%  4.12Ki.rela.dyn
   0.6%  2.56Ki   0.0%   0[ELF Section Headers]
   0.3%  1.52Ki   0.6%  1.52Ki.rela.plt
   0.3%  1.47Ki   0.5%  1.47Ki.gnu.version
   0.2%  1.03Ki   0.4%  1.03Ki.plt
   0.2% 728   0.3% 728[ELF Program Headers]
 100.0%   441Ki 100.0%   273KiTOTAL
```

(`.debug_rnglists` and `.debug_abbrev` do not even register).





```
$ ~/bloaty/build/bloaty binary-O3-g-g3.exe  # without debug 
sections (broken lines in stack trace)

FILE SIZEVM SIZE
 --  --
  26.9%   107Ki  39.3%   107Ki.text
  23.2%  92.9Ki   0.0%   0.strtab
  16.3%  65.3Ki  23.8%  65.3Ki.dynstr
   7.1%  28.5Ki  10.4%  28.5Ki.rodata
   6.9%  27.9Ki  10.2%  27.9Ki.eh_frame
   6.2%  24.7Ki   0.0%   0.symtab
   4.4%  17.6Ki   6.4%  17.6Ki.dynsym
   1.8%  7.25Ki   0.0%   0[Unmapped]
   1.5%  6.18Ki   2.3%  6.18Ki.eh_frame_hdr
   1.3%  5.08Ki   1.9%  5.08Ki.gnu.hash
   1.1%  4.31Ki   1.6%  4.31Ki.data.rel.ro
   1.0%  4.12Ki   1.5%  4.12Ki.rela.dyn
   0.5%  2.12Ki   0.0%   0[ELF Section Headers]
   0.4%  1.52Ki   0.6%  1.52Ki.rela.plt
   0.4%  1.47Ki   0.5%  1.47Ki.gnu.version
   0.3%  1.18Ki   0.3% 881[18 Others]
   0.3%  1.03Ki   0.4%  1.03Ki.plt
   0.2% 728   0.3% 728[ELF Program Headers]
   0.1% 552   0.2% 552.data
   0.1% 544   0.2% 544.got.plt
   0.1% 512   0.2% 512.dynamic
 100.0%   401Ki 100.0%   273KiTOTAL
```

```
$ ~/bloaty/build/bloaty binary-O3-g-g3.debug   # only debug 
sections

FILE SIZEVM SIZE
 --  --
  31.0%   178Ki   0.0%   0.debug_info
   0.0%   0  39.3%   107Ki.text
  18.5%   106Ki   0.0%   0.debug_loclists
  16.8%  96.9Ki   0.0%   0.debug_str
  16.1%  93.0Ki   0.0%   0.strtab
   0.0%   0  23.8%  65.3Ki.dynstr
  10.5%  60.7Ki   0.0%   0.debug_line
   0.0%   0  10.4%  28.5Ki.rodata
   0.0%   0  10.2%  27.9Ki.eh_frame
   4.3%  24.8Ki   0.0%   0.symtab
   0.0%   0   6.4%  17.6Ki.dynsym
   0.0%   0   2.3%  6.18Ki.eh_frame_hdr
   1.0%  5.86Ki   0.0%   0.debug_rnglists
   0.0%   0   1.9%  5.08Ki.gnu.hash
   0.8%  4.54Ki   0.0%   0.debug_abbrev
   0.0%   0   1.6%  4.31Ki.data.rel.ro
   0.5%  2.79Ki   1.5%  4.17Ki[27 Others]
   0.0%   0   1.5%  4.12Ki.rela.dyn
   0.5%  2.69Ki   0.0%   0[ELF Section Headers]
   0.0%   0   0.6%  1.52Ki.rela.plt
   0.0%   0   0.5%  1.47Ki

Reducing debug info for stack traces, while preserving for gdb

[Witold Baryluk via D.gnu]

Hi,

I am trying to split debug symbols out of final binary, to reduce 
its size. But I would like to preserve at least line numbers in 
the stacktraces from `Exception`s.


Linux, amd64. gdc 12.2.0 on Debian testing.

Binary is compiled using `-O3 -g -g3` (and possibly -gz).

I then use `objcopy` to split debug info from final ELF binary 
file into .exe and .debug files.


I use `objcopy --only-keep-debug --compress-debug-sections=zlib 
binary binary.debug` to produce .debug file.


Then I use normally `objcopy --strip-debug binary binary.exe` 
(possibly with --compress-debug-sections=zlib) to produce binary.


This makes it possibly to use in gdb without issues (using `gdb 
-s binary.debug -e binary` for example, or by utilizing 
`--add-gnu-debuglink=` option in `objcopy`).


But this causes stacktraces to miss line numbers (and columns). 
(function names are still there, as these are derived from symbol 
tables instead).


I tried selectively removing DWARF debug sections, but it looks 
that at least these are required:


`.debug_info`
`.debug_aranges`
`.debug_abbrev`
`.debug_line`
`.debug_str`
`.debug_line_str`
`.debug_rnglists`

So, I can only remove these:

`objcopy -R .debug_loc -R .debug_macro -R .debug_ranges -R 
.debug_loclists`


(`.debug_loc` and `.debug_ranges` are not even generated by gcc, 
so it does not matter probably).


The issue is, this saves me very little space. `.debug_macro` and 
`.debug_loclists` are rather small.


The bulk of information is in `.debug_info`. But I believe it 
contains way more information than is really needed to just 
produce line numbers.




I did inspect final binaries , and it is using DWARF version 5.

I also tried `-gas-loc-support` , but no change.

Using `-g1` makes stack traces work nicely, by making 
`.debug_info` smaller, but then debugging in `gdb` is very 
limited. One option would be to compile application twice, once 
with `-g1` and once with `-g3`. But I really do not think this is 
supported, or reliable, even if I enable deterministic builds.


In one article ( 
https://support.backtrace.io/hc/en-us/articles/360040105792-DWARF#RemovingDebugInformation )  I read that for C/C++ in GCC, it is enough to preserve only `.debug_frame` and `.debug_line` to get function, source filenames and line numbers. But that is not true for gdc and its stacktrace handler.



I did read about this gdb extension, which is interesting, 
https://sourceware.org/gdb/onlinedocs/gdb/MiniDebugInfo.html , 
but I did not try, and it is probably only supported in gdb (i.e. 
addr2libe, Phobos, libunwind do not  support it).



Any ideas?

Re: Building i386 D runtime on OS X

[teverett via D.gnu]

On Sunday, 25 September 2022 at 06:03:32 UTC, Iain Buclaw wrote:

On Saturday, 24 September 2022 at 23:05:28 UTC, teverett wrote:

[...]


Hi,

I assume that this is for the [ldc 
group](https://forum.dlang.org/group/ldc) instead of gdc.


Generically, building druntime should be fine, you'll need a 
sufficiently old enough version of osx to run 32-bit binaries - 
I forget when they dropped multilib support, around 10.9? - 
which means that there might be some missing symbols reported 
when building Phobos (posix_memalign might be one).


oh, thank you for your reply.  I'll repost to the LDC group.

Re: Building i386 D runtime on OS X

[Iain Buclaw via D.gnu]

On Saturday, 24 September 2022 at 23:05:28 UTC, teverett wrote:

Hello, I am following the instructions here:

https://wiki.dlang.org/Building_LDC_runtime_libraries

I'm on OSX and need a ELF D RTL for i386.

I've used HomeBrew to install x86_64-elf-gcc, ninja and cmake.  
The command I'm issuing is:


`CC=/usr/local/Cellar/x86_64-elf-gcc/12.2.0/bin/x86_64-elf-gcc 
ldc-build-runtime --ninja --dFlags="-mtriple=i386-none-elf"

`



Hi,

I assume that this is for the [ldc 
group](https://forum.dlang.org/group/ldc) instead of gdc.


Generically, building druntime should be fine, you'll need a 
sufficiently old enough version of osx to run 32-bit binaries - I 
forget when they dropped multilib support, around 10.9? - which 
means that there might be some missing symbols reported when 
building Phobos (posix_memalign might be one).

Building i386 D runtime on OS X

[teverett via D.gnu]

Hello, I am following the instructions here:

https://wiki.dlang.org/Building_LDC_runtime_libraries

I'm on OSX and need a ELF D RTL for i386.

I've used HomeBrew to install x86_64-elf-gcc, ninja and cmake.  
The command I'm issuing is:


`CC=/usr/local/Cellar/x86_64-elf-gcc/12.2.0/bin/x86_64-elf-gcc 
ldc-build-runtime --ninja --dFlags="-mtriple=i386-none-elf"

`

I'm getting the below result. Is there a known way to get past 
the `search_paths` issue? Or perhaps a better way to build the 
i386 elf RT on OS X?



> 
CC=/usr/local/Cellar/x86_64-elf-gcc/12.2.0/bin/x86_64-elf-gcc 
ldc-build-runtime --ninja --dFlags="-mtriple=i386-none-elf"

.: Creating build directory: ldc-build-runtime.tmp
.: Downloading LDC source archive: 
https://github.com/ldc-developers/ldc/releases/download/v1.30.0/ldc-1.30.0-src.zip
.: Invoking: cmake 
-DLDC_EXE_FULL=/usr/local/Cellar/ldc/1.30.0_1/bin/ldc2 
-DDMDFE_MINOR_VERSION=100 -DDMDFE_PATCH_VERSION=1 
-DD_EXTRA_FLAGS=-mtriple=i386-none-elf -G Ninja 
/Users/tom/projects/ados/src/ldc-build-runtime.tmp/ldc-src/runtime

-- The C compiler identification is GNU 12.2.0
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target 
flag
-- Checking whether C compiler supports OSX deployment target 
flag - no

-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: 
/usr/local/Cellar/x86_64-elf-gcc/12.2.0/bin/x86_64-elf-gcc
-- Check for working C compiler: 
/usr/local/Cellar/x86_64-elf-gcc/12.2.0/bin/x86_64-elf-gcc - 
broken
CMake Error at 
/usr/local/Cellar/cmake/3.24.2/share/cmake/Modules/CMakeTestCCompiler.cmake:69 (message):

  The C compiler


"/usr/local/Cellar/x86_64-elf-gcc/12.2.0/bin/x86_64-elf-gcc"


  is not able to compile a simple test program.

  It fails with the following output:

Change Dir: 
/Users/tom/projects/ados/src/ldc-build-runtime.tmp/CMakeFiles/CMakeTmp


Run Build Command(s):/usr/local/bin/ninja cmTC_75803 && 
[1/2] Building C object 
CMakeFiles/cmTC_75803.dir/testCCompiler.c.o

[2/2] Linking C executable cmTC_75803
FAILED: cmTC_75803
: && 
/usr/local/Cellar/x86_64-elf-gcc/12.2.0/bin/x86_64-elf-gcc 
-isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.3.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/usr/local/opt/libpq/lib CMakeFiles/cmTC_75803.dir/testCCompiler.c.o -o cmTC_75803   && :
/usr/local/opt/x86_64-elf-binutils/bin/x86_64-elf-ld: 
Error: unable to disambiguate: -search_paths_first (did you mean 
--search_paths_first ?)

collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:1 (project)


-- Configuring incomplete, errors occurred!
See also 
"/Users/tom/projects/ados/src/ldc-build-runtime.tmp/CMakeFiles/CMakeOutput.log".
See also 
"/Users/tom/projects/ados/src/ldc-build-runtime.tmp/CMakeFiles/CMakeError.log".

.: Error: command failed with status 1

Re: Looking to make a GDC-12 mingw64 package

[Preetpal via D.gnu]

There are more issues with the GDC 11.3.0 that I compiled on 
Windows earlier (it was compiled with win32 threads). The 
following code has issues compiling (find_file.d):


```
import std.file;
import std.stdio;

/// Command line tool to find files in directories
int main(string[] args) {
if (args.length < 2) {
writefln("Usage: %s wildcard", args[0]);
return 1;
}
string wildcard = args[1];

auto results = dirEntries(".", wildcard, SpanMode.depth);
foreach(string result; results) {
writeln(result);
}
return 0;
}
```

The following is a log of the compilation:


```
preet@DESKTOP MINGW64 
/b/D/gdc/MINGW-packages-gdc-11.3.0-build/mingw-w64-gdc/tests_for_d_compiler

$ ../src/mingw64/bin/gdc.exe -v
Using built-in specs.
COLLECT_GCC=B:\D\gdc\MINGW-packages-gdc-11.3.0-build\mingw-w64-gdc\src\mingw64\bin\gdc.exe
COLLECT_LTO_WRAPPER=B:/D/gdc/MINGW-packages-gdc-11.3.0-build/mingw-w64-gdc/src/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-11.3.0/configure --prefix=/mingw64 
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 
--with-native-system-header-dir=/mingw64/include 
--libexecdir=/mingw64/lib --enable-bootstrap 
--enable-checking=release --with-arch=x86-64 --with-tune=generic 
--enable-languages=d --enable-shared --enable-static 
--enable-libatomic --enable-graphite 
--enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts 
--enable-libstdcxx-time --disable-libstdcxx-pch --enable-lto 
--enable-libgomp --enable-libphobos --disable-multilib 
--disable-rpath --disable-win32-registry --disable-nls 
--disable-werror --disable-symvers --with-libiconv 
--with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 
--with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev2, 
Built by MSYS2 project' 
--with-bugurl=https://github.com/msys2/MINGW-packages/issues 
--with-gnu-as --with-gnu-ld --disable-libstdcxx-debug 
--with-boot-ldflags=-static-libstdc++ 
--with-stage1-ldflags=-static-libstdc++

Thread model: win32
Supported LTO compression algorithms: zlib zstd
gcc version 11.3.0 (Rev2, Built by MSYS2 project)

preet@DESKTOP MINGW64 
/b/D/gdc/MINGW-packages-gdc-11.3.0-build/mingw-w64-gdc/tests_for_d_compiler

$ ../src/mingw64/bin/gdc.exe find_file.d
C:\msys64\mingw64\bin/ld.exe: 
B:/D/gdc/MINGW-packages-gdc-11.3.0-build/mingw-w64-gdc/src/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.3.0/../../../../lib\libgphobos.a(socket.o): in function `_D3std6socket8Protocol17getProtocolByTypeMFNbNeEQBuQBt12ProtocolTypeZb':

B:\D\gdc\MINGW-packages-gdc-11.3.0-build\mingw-w64-gdc\src\build-x86_64-w64-mingw32\x86_64-w64-mingw32\libphobos\src/../../../../gcc-11.3.0/libphobos/src/std/socket.d:443:
 undefined reference to `getprotobynumber'
C:\msys64\mingw64\bin/ld.exe: 
B:/D/gdc/MINGW-packages-gdc-11.3.0-build/mingw-w64-gdc/src/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.3.0/../../../../lib\libgphobos.a(socket.o): in function `_D3std6socket15InternetAddress4portMxFNaNbNdNiNfZt':

B:\D\gdc\MINGW-packages-gdc-11.3.0-build\mingw-w64-gdc\src\build-x86_64-w64-mingw32\x86_64-w64-mingw32\libphobos\src/../../../../gcc-11.3.0/libphobos/src/std/socket.d:1504:
 undefined reference to `ntohs'
C:\msys64\mingw64\bin/ld.exe: 
B:/D/gdc/MINGW-packages-gdc-11.3.0-build/mingw-w64-gdc/src/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.3.0/../../../../lib\libgphobos.a(socket.o): in function `_D3std6socket15InternetAddress4addrMxFNaNbNdNiNfZk':

B:\D\gdc\MINGW-packages-gdc-11.3.0-build\mingw-w64-gdc\src\build-x86_64-w64-mingw32\x86_64-w64-mingw32\libphobos\src/../../../../gcc-11.3.0/libphobos/src/std/socket.d:1510:
 undefined reference to `ntohl'
C:\msys64\mingw64\bin/ld.exe: 
B:/D/gdc/MINGW-packages-gdc-11.3.0-build/mingw-w64-gdc/src/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.3.0/../../../../lib\libgphobos.a(socket.o): in function `_D3std6socket16Internet6Address4portMxFNaNbNdNiNfZt':

B:\D\gdc\MINGW-packages-gdc-11.3.0-build\mingw-w64-gdc\src\build-x86_64-w64-mingw32\x86_64-w64-mingw32\libphobos\src/../../../../gcc-11.3.0/libphobos/src/std/socket.d:1775:
 undefined reference to `ntohs'
C:\msys64\mingw64\bin/ld.exe: 
B:/D/gdc/MINGW-packages-gdc-11.3.0-build/mingw-w64-gdc/src/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.3.0/../../../../lib\libgphobos.a(socket.o): in function `_D3std6socket6Socket7isAliveMxFNdNeZb':

B:\D\gdc\MINGW-packages-gdc-11.3.0-build\mingw-w64-gdc\src\build-x86_64-w64-mingw32\x86_64-w64-mingw32\libphobos\src/../../../../gcc-11.3.0/libphobos/src/std/socket.d:2764:
 undefined reference to `getsockopt'
C:\msys64\mingw64\bin/ld.exe: 
B:/D/gdc/MINGW-packages-gdc-11.3.0-build/mingw-w64-gdc/src/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.3.0/../../../../lib\libgphobos.a(socket.o): in function `_D3std6socket6Socket8shutdownMFNbNiNeEQBkQBj14SocketShutdownZv':