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'?

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.

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?

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).

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.

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"

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.