www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Compiler is calling `_memset64` in betterC

reply Koro <KoromoriX yahoo.com> writes:
I'm writing a 'betterC' program and the compiler is generating a 
call to '_memset64' if I have an array literal where the elements 
are the same.

```
extern(C) void main() {
	f([1, 1]);
}

void f(scope immutable ulong[] a) {}
```

Running `dmd -betterC app.d` fails with:

```
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
app.o: in function `main':
app.d:(.text.main[main]+0x24): undefined reference to `_memset64'
collect2: error: ld returned 1 exit status
Error: linker exited with status 1
``

I don't want to link to additional libraries (planning to target 
WASM). The code works if I write `ulong i = 1; f([i, i]);`, but 
I'd rather the code worked without having to trick the compiler. 
Is there a compiler flag I could set to prevent D from inserting 
calls to '_memset64'?
Oct 18 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 18 October 2020 at 16:04:55 UTC, Koro wrote:

 I'm writing a 'betterC' program and the compiler is generating 
 a call to '_memset64' if I have an array literal where the 
 elements are the same.


It's a known bug:

https://issues.dlang.org/show_bug.cgi?id=17778

My guess is that the reason it hasn't been fixed is that (a) it's 
possible to work around it, and (b) the problem is in the 
compiler backend, and few people understand that code well enough 
to fix it.
Oct 18 2020
parent reply Neto <business.mongol2525 gmail.com> writes:
On Sunday, 18 October 2020 at 16:12:59 UTC, Paul Backus wrote:

 On Sunday, 18 October 2020 at 16:04:55 UTC, Koro wrote:

 I'm writing a 'betterC' program and the compiler is generating 
 a call to '_memset64' if I have an array literal where the 
 elements are the same.


 It's a known bug:

 https://issues.dlang.org/show_bug.cgi?id=17778

 My guess is that the reason it hasn't been fixed is that (a) 
 it's possible to work around it, and (b) the problem is in the 
 compiler backend, and few people understand that code well 
 enough to fix it.


I plan to start a project in reasonable size, I wonder if I 
should really use betterC... if I encounter a bug like this, will 
I be stuck at it?
Oct 18 2020
parent reply Ferhat =?UTF-8?B?S3VydHVsbXXFnw==?= <aferust gmail.com> writes:
On Sunday, 18 October 2020 at 17:05:01 UTC, Neto wrote:

 On Sunday, 18 October 2020 at 16:12:59 UTC, Paul Backus wrote:

 On Sunday, 18 October 2020 at 16:04:55 UTC, Koro wrote:

 I'm writing a 'betterC' program and the compiler is 
 generating a call to '_memset64' if I have an array literal 
 where the elements are the same.


 It's a known bug:

 https://issues.dlang.org/show_bug.cgi?id=17778

 My guess is that the reason it hasn't been fixed is that (a) 
 it's possible to work around it, and (b) the problem is in the 
 compiler backend, and few people understand that code well 
 enough to fix it.


 I plan to start a project in reasonable size, I wonder if I 
 should really use betterC... if I encounter a bug like this, 
 will I be stuck at it?


The bug report says, it is a dmd specific problem, and LDC, my 
favorite d compiler, works well (tried it).
Oct 18 2020
parent reply matheus <matheus gmail.com> writes:
On Sunday, 18 October 2020 at 19:24:28 UTC, Ferhat Kurtulmuş 
wrote:

 I plan to start a project in reasonable size, I wonder if I 
 should really use betterC... if I encounter a bug like this, 
 will I be stuck at it?


 The bug report says, it is a dmd specific problem, and LDC, my 
 favorite d compiler, works well (tried it).


So the "first party" compiler has a bug while the "third party" 
one works. That's weird.

I would expect the other way around.

Matheus.
Oct 19 2020
next sibling parent Ferhat =?UTF-8?B?S3VydHVsbXXFnw==?= <aferust gmail.com> writes:
On Monday, 19 October 2020 at 14:07:38 UTC, matheus wrote:

 On Sunday, 18 October 2020 at 19:24:28 UTC, Ferhat Kurtulmuş 
 wrote:

 I plan to start a project in reasonable size, I wonder if I 
 should really use betterC... if I encounter a bug like this, 
 will I be stuck at it?


 The bug report says, it is a dmd specific problem, and LDC, my 
 favorite d compiler, works well (tried it).


 So the "first party" compiler has a bug while the "third party" 
 one works. That's weird.

 I would expect the other way around.

 Matheus.


Ldc is used and tested more. An answer to this thread explains 
the situation.

From:

https://stackoverflow.com/questions/62265658/undefined-reference-to-memset64-when-creating-a-struct-array-under-dmd-with?r=SearchResults

"I would highly recommend that you do not use DMD and instead 
stick to either LDC or GDC. They have far more tested and 
performant code generator, and have support for many more 
platforms. The debug info they generate will also be much better, 
and they have support for your use case (bare metal). – Geod24 
Jun 10 at 3:30"
Oct 19 2020
prev sibling parent Paul Backus <snarwin gmail.com> writes:
On Monday, 19 October 2020 at 14:07:38 UTC, matheus wrote:

 On Sunday, 18 October 2020 at 19:24:28 UTC, Ferhat Kurtulmuş 
 wrote:

 I plan to start a project in reasonable size, I wonder if I 
 should really use betterC... if I encounter a bug like this, 
 will I be stuck at it?


 The bug report says, it is a dmd specific problem, and LDC, my 
 favorite d compiler, works well (tried it).


 So the "first party" compiler has a bug while the "third party" 
 one works. That's weird.

 I would expect the other way around.

 Matheus.


This is more or less the norm for backend issues in D.

The ldc and gdc backends are shared with clang and gcc, so they 
are very well-maintained and bugs in them tend to get fixed 
quickly. The dmd backend, on the other hand, is maintained by 
only a small handful of people.
Oct 19 2020