Re: Lack of asm volatile qualifier (explicitly) again.

2020-08-01 Thread Iain Buclaw via Digitalmars-d-learn
On Saturday, 1 August 2020 at 02:36:41 UTC, Cecil Ward wrote: On Thursday, 30 July 2020 at 07:05:39 UTC, Iain Buclaw wrote: [...] Ah. I wasn’t thinking about pure, although I do use it everywhere I can as a matter of course. The absence of something doesn’t hit you in the eye as an

Re: Lack of asm volatile qualifier (explicitly) again.

2020-07-30 Thread Iain Buclaw via Digitalmars-d-learn
On Tuesday, 28 July 2020 at 06:57:36 UTC, Cecil Ward wrote: I read recently that all asm in D is regarded as ‘volatile’ in the GCC sense, which I take to mean that it is assume to potentially have side effects, and so cannot be optimised away to nothing by the compiler despite the lack of any

Re: Template error with gdc-10 but not with latest dmd and ldc

2020-07-26 Thread Iain Buclaw via Digitalmars-d-learn
On Sunday, 26 July 2020 at 19:27:13 UTC, rikki cattermole wrote: 2.066.0 to 2.078.1: Failure with output: onlineapp.d(7): Error: template instance add_long_n0!void does not match template declaration add_long_n0(alias T = void)(long x) 2.079.1 to 2.086.1: Failure with output: onlineapp.d(7):

Re: odd atomicOp errors from vibe-core

2020-04-12 Thread Iain Buclaw via Digitalmars-d-learn
On Friday, 10 April 2020 at 01:54:14 UTC, Steven Schveighoffer wrote: I'm building a library that uses vibe-core as an indirect dependency. Specifically, I'm testing the library with dub test. A very odd thing happens as I'm picking off compiler errors one at a time. After all the errors that

Re: Porting D to custom OS

2020-02-22 Thread Iain Buclaw via Digitalmars-d-learn
On Saturday, 22 February 2020 at 13:20:40 UTC, IGotD- wrote: I'm trying to find information how to port D, especially the D runtime to a proprietary OS. The OS support seems to be scattered around several files with a lot version (OS) switches. This makes kind of hard to understand what you

Re: GCC 4.9.4 + GDC-patch: internal compiler error in libphobos/src/std/math.d:8040:47

2019-01-06 Thread Iain Buclaw via Digitalmars-d-learn
On Saturday, 5 January 2019 at 22:27:49 UTC, kdevel wrote: I applied the head commit ce249d880969111384d17f744687e427c843f1d4 Merge: 8a6b7a4 0e517e4 Author: Eugene Wissner Date: Tue Apr 10 15:37:32 2018 +0200 Merge pull request #647 from belka-ew/gdc-49up Merge

Re: Alignment of struct containing SIMD field - GDC

2017-03-01 Thread Iain Buclaw via Digitalmars-d-learn
On Wednesday, 1 March 2017 at 19:09:24 UTC, Johan Engelen wrote: On Wednesday, 1 March 2017 at 18:34:16 UTC, Iain Buclaw wrote: Simple test case would be: struct vec_struct { bool b2; struct { bool b; int8 field; } } static assert(vec_struct.b.offsetof == 32);

Re: Alignment of struct containing SIMD field - GDC

2017-03-01 Thread Iain Buclaw via Digitalmars-d-learn
On Wednesday, 1 March 2017 at 06:04:32 UTC, Cecil Ward wrote: struct vec_struct { alias field this; bool b; int8 field; } In this code when you look at the generated x64 code output by GDC it seems to be doing a nice job, because it has got the offset right for the 256-bit YMM

Re: union alignment

2016-05-21 Thread Iain Buclaw via Digitalmars-d-learn
On Wednesday, 18 May 2016 at 01:46:37 UTC, tsbockman wrote: Shouldn't a union type always have an `alignof` at least as great as the `alignof` for its largest member? On x86, there's a difference between the type alignment and the field alignment. The type align of ulong and double are 8

Re: fromStringz problem with gdc

2015-04-06 Thread Iain Buclaw via Digitalmars-d-learn
On Monday, 6 April 2015 at 17:47:27 UTC, chardetm wrote: Hello everyone, I have a problem with the fromStringz function (std.string.fromStringz) when I try to compile with the GDC compiler (it works fine with DMD). Here is a minimal code to see the error: import std.stdio, std.string,

Re: Method signature differences in core modules on dmd and gdc?

2014-10-12 Thread Iain Buclaw via Digitalmars-d-learn
On Sunday, 12 October 2014 at 19:20:49 UTC, Gary Willoughby wrote: I've been recently trying GDC out to compile some D code and i'm running into the problem of differing function signatures in core modules. For example: stack.d:79: error: function core.memory.GC.calloc (ulong sz, uint ba =