Re: real.sizeof

[Iain Buclaw via Digitalmars-d-learn]

On Monday, 5 February 2024 at 16:45:03 UTC, Dom DiSc wrote:

Why is real.sizeof == 16 on x86-systems?!?
Its the IEEE 754 extended format: 64bit mantissa + 15bit 
exponent + sign.

It should be size 10!
I mean, alignment may be different, but why wasting so much 
memory even in arrays?


Padding.

x86 ABI prefers things to be aligned, so on x86 it's 12 bytes, 
x86_64 16 bytes.  In both cases you don't get any extra precision 
over the 80-bits that x87 gives you.

Re: Spec for the ‘locality’ parameter to the LDC and GDC builtin magic functions for accessing special CPU prefetch instructions

[Iain Buclaw via Digitalmars-d-learn]

On Saturday, 19 August 2023 at 19:23:38 UTC, Cecil Ward wrote:


I’m trying to write a cross-platform function that gives access 
to the CPU’s prefetch instructions such as x86 
prefetch0/1/2/prefetchnta and AAarch64 too. I’ve found that the 
GDC and LDC compilers provide builtin magic functions for this, 
and are what I need. I am trying to put together a 
plain-English detailed spec for the respective builtin magic 
functions.


My questions:

Q1) I need to compare the spec for the GCC and LDC builtin 
magic functions’ "locality" parameter. Can anyone tell me if 
GDC and LDC have kept mutual compatibility here?




I'd have thought GCC and LLVM have mutual compatibility thanks to 
a common target API in Intel's `_mm_prefetch()` function (and in 
fact, the magic locality numbers match `_MM_HINT_*` constants).


```
#define _MM_HINT_T0 1
#define _MM_HINT_T1 2
#define _MM_HINT_T2 3
#define _MM_HINT_NTA 0
```

Q2) Could someone help me turn the GCC and LDC specs into 
english regarding the locality parameter ? - see (2) and (4) 
below.



https://gcc.gnu.org/projects/prefetch.html




Q3) Does the locality parameter determine which _level_ of the 
data cache hierarchy data is fetched into? Or is it always 
fetched into L1 data cache and the outer ones, and this 
parameter affects caches’ _future behaviour_?




It really depends on the CPU, and what features it has.

x86 SSE intrinsics are described in the x86 instruction manual, 
along with the meaning of T[012], and NTA.


https://www.felixcloutier.com/x86/prefetchh



Q3) Will these magic builtins work on AAarch64?



It'll work on all targets that define a prefetch insn, or it'll 
be a no-op.  Similarly one or both read-write or locality 
arguments might be ignored too.

Re: Generate a pointer to a method of a struct

[Iain Buclaw via Digitalmars-d-learn]

On Friday, 14 October 2022 at 18:34:58 UTC, kdevel wrote:
dmd and gdc optimize the lambda invocations away. Nonetheless 
the expression looks somewhat too big. To overcome this I tried 
to generate the function pointer outside of the struct:


```
auto funcptr (alias method) ()
{
   return &method;
}
  :
  fun = funcptr!bar;
  :
```

Which works but neither dmd nor gdc were able to optimize the 
additional function call away.


pragma(inline, true)
auto funcptr (alias method) ()

Re: Problem with GC - linking C++ & D (with gdc)

[Iain Buclaw via Digitalmars-d-learn]

On Tuesday, 26 April 2022 at 10:23:15 UTC, Claude wrote:

Hello,



Hello,

<%--SNIP--%>



Does anyone have any idea what's going on?

(if I just compile a single D file with "int main() { int* a = 
new int(42); return *a; }", it works as intended.)


The `new` keyword requests the druntime GC to allocate memory, 
however you haven't initialized the D run-time in your program.


main.cpp
```D
extern "C" int rt_init();
extern "C" const int* ct_parse();

int main(int argc, char ** argv)
{
rt_init();
return *ct_parse();
}
```

Re: gdc or ldc for faster programs?

[Iain Buclaw via Digitalmars-d-learn]

On Monday, 31 January 2022 at 10:33:49 UTC, Siarhei Siamashka 
wrote:

I wonder if GDC can do the same?


GDC as a front-end doesn't dictate what the optimization passes 
are doing, nor does it have any real control what each level 
means.  It is only ensured that semantic doesn't break because of 
an optimization pass.

Re: gdc or ldc for faster programs?

[Iain Buclaw via Digitalmars-d-learn]

On Thursday, 27 January 2022 at 20:28:40 UTC, Siarhei Siamashka 
wrote:
On Thursday, 27 January 2022 at 18:12:18 UTC, Johan Engelen 
wrote:
But the language requires ODR, so we can emit templates as 
weak_odr, telling the optimizer and linker that the symbols 
should be merged _and_ that ODR can be assumed to hold (i.e. 
inlining is OK).


Thanks! This was also my impression. But the problem is that 
Iain Buclaw seems to disagree with us. He claims that template 
functions must be overridable by global functions and this is 
supposed to inhibit template functions inlining. Is there any 
independent source to back up your or Iain's claim?




For example, druntime depends on this behaviour.

Template: 
https://github.com/dlang/druntime/blob/a0ad8c42c15942faeeafb016e81a360113ae1b6b/src/rt/config.d#L46-L58


Regular symbol: 
https://github.com/dlang/druntime/blob/a17bb23b418405e1ce8e4a317651039758013f39/test/config/src/test19433.d#L1


If we can rely on instantiated symbols to not violate ODR, then 
you would be able to put symbols in the .link-once section.  
However all duplicates must also be in the .link-once section, 
else you'll get duplicate definition errors.

Re: gdc or ldc for faster programs?

[Iain Buclaw via Digitalmars-d-learn]

On Wednesday, 26 January 2022 at 18:39:07 UTC, Siarhei Siamashka 
wrote:


It's not DMD doing a good job here, but GDC11 shooting itself 
in the foot by requiring additional  esoteric command line 
options if you really want to produce optimized binaries.


The D language shot itself in the foot by requiring templates to 
have weak semantics.


If DMD and LDC inline weak functions, that's their bug.

Re: gdc or ldc for faster programs?

[Iain Buclaw via Digitalmars-d-learn]

On Wednesday, 26 January 2022 at 11:43:39 UTC, forkit wrote:
On Wednesday, 26 January 2022 at 11:25:47 UTC, Iain Buclaw 
wrote:


Whenever I've watched talks/demos where benchmarks were the 
central topic, GDC has always blown LDC out the water when it 
comes to matters of math.

..


https://dlang.org/blog/2020/05/14/lomutos-comeback/


Andrei forgot to do a follow up where one weird trick makes the 
gdc compiled lumutos same speed as C++ (and faster than ldc).


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

Re: gdc or ldc for faster programs?

[Iain Buclaw via Digitalmars-d-learn]

On Wednesday, 26 January 2022 at 04:28:25 UTC, Ali Çehreli wrote:

On 1/25/22 16:15, Johan wrote:
> On Tuesday, 25 January 2022 at 19:52:17 UTC, Ali Çehreli
wrote:
>>
>> I am using compilers installed by Manjaro Linux's package
system:
>>
>> ldc: LDC - the LLVM D compiler (1.28.0):
>>   based on DMD v2.098.0 and LLVM 13.0.0
>>
>> gdc: dc (GCC) 11.1.0
>>
>> dmd: DMD64 D Compiler v2.098.1
>
> What phobos version is gdc using?

Oh! Good question. Unfortunately, I don't think Phobos modules 
contain that information. The following line outputs 2076L:


pragma(msg, __VERSION__);

So, I guess I've been comparing apples to oranges but in this 
case an older gdc is doing pretty well.




Doubt it.  Functions such as to(), map(), etc. have pretty much 
remained unchanged for the last 6-7 years.


Whenever I've watched talks/demos where benchmarks were the 
central topic, GDC has always blown LDC out the water when it 
comes to matters of math.


Even in more recent examples where I've been pushing for native 
complex to be replaced with std.complex, LDC was found to be 
slower with std.complex, but GDC was either equal, or faster than 
native (and GDC std.complex was faster than LDC).

Re: Debugging D code with GDB

[Iain Buclaw via Digitalmars-d-learn]

On Monday, 29 November 2021 at 14:48:21 UTC, Luís Ferreira wrote:
On Sun, 2021-11-28 at 21:59 +, Iain Buclaw via 
Digitalmars-d-learn wrote:


DMD doesn't emit this information. GDB can't work miracles 
when the compiler isn't pulling its own weight.


I confirm this is an issue with DMD. I filed a bug in the issue 
tracker, in case you want to follow: 
https://issues.dlang.org/show_bug.cgi?id=22551


Anyway, DMD exports the symbol, it should work if you do 
something like `myPrint(&s)`, but I think there is another 
problem on calling it, due to defective calling convention on 
both DMD and LDC implementations.


LDC exports the symbol correctly, although.


Indeed, gdb assumes calling convention is same as default for 
target (actually its been years since I last looked, but are 
calling conventions tags in dwarf? Does gdb know about functions 
with thiscall or regparm attributes?)


Another thing on the gdb side, it is currently missing D language 
support for overloads, so that the correct function would be 
picked when you call e.g std.math.sin(1f).

Re: Debugging D code with GDB

[Iain Buclaw via Digitalmars-d-learn]

On Saturday, 27 November 2021 at 14:17:11 UTC, Eduard Staniloiu 
wrote:

Hello,

I'm trying to use `gdb` to debug D binaries, but I'm having 
trouble accessing the methods of a struct or class. It seems 
that `gdb` doesn't see them.


Given the following simple example
```
// test.d
struct S
{
int x;

void myPrint() { writefln("x is %s\n", x); }
}

void main(string[] args)
{
S s;
}
```
Compile the source file with debug simbols (`dmd -g test.d 
-of=test`) and open the binary with gdb (`gdb test`) and run 
the following


```

break _Dmain # break at D entry point
run
ptype s

type = struct test.S {
int x;
}

print s.myPrint()

Structure has no component named myPrint.
```

As you can see, when I try to access the `myPrint()` method I 
get the error

"Structure has no component named myPrint."



DMD doesn't emit this information. GDB can't work miracles when 
the compiler isn't pulling its own weight.

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

[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 expression of the 
programmer’s intent I suppose, absence of pure just could mean 
the author forgot to put it in. I see your point though. The 
value of volatile I saw as in documentation.


When the baseline for asm is volatile, I don't think it's 
entirely surprising to consider pure as a cancellation of that - 
afterall, if it truly is side-effect free, then it's fine for the 
compiler to remove the statement block.

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

[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 outputs.


I would like to be able to either use the asm volatile 
qualifier now and have it do absolutely nothing or else have an 
alternative way of expressing the licence for optimisation 
allowed by the designer. If it is now way too late to declare 
that suddenly the _lack_ of volatile means that the compiler 
can go optimisation-crazy, then we need some alternative 
‘is_optimisable’ keyword.




Until recently the absence of the pure keyword implied volatile 
in gdc. I do plan to re-add it, either only in release mode, or 
when warnings are added for the following:


---
asm pure {
  "get flags" : "=r" (x);
}
assert(x == 1);

asm {
  "set flags" : : "r" (x + 1);
}

asm pure {
  "get flags" : "=r" (x);
}
assert(x == 2);
---

The second 'get flags' would be removed if optimizing as it is 
both identical to the first statement, and not clear to the 
compiler that there is a dependency between the setter and getter 
statements.


Just highlighting one example that might be surprising if you 
weren't thinking that optimizing mean that as well.

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

[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): Error: 
template instance `add_long_n0!void` does not match template 
declaration `add_long_n0(alias T = void)(long x)`

Since  2.087.1: Success and no output


This feature?

https://dlang.org/changelog/2.087.0.html#template_alias_matches_basic_types

Re: odd atomicOp errors from vibe-core

[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 I created are listed, I 
get this list:




[--snip--]

Error: template core.atomic.atomicOp cannot deduce function 
from argument types !("-=")(shared(uint), int), candidates are:

/home/steves/.dvm/compilers/dmd-2.091.0/linux/bin/../../src/druntime/import/core/atomic.d(543,14):
   atomicOp(string op, T, V1)(ref shared T val, V1 mod)
  with op = "-=",
   T = uint,
   V1 = int
  must satisfy the following constraint:
   __traits(compiles, mixin("*cast(T*)&val" ~ op ~ "mod"))


[--snip--]


../../../.dub/packages/vibe-core-1.9.0/vibe-core/source/vibe/core/sync.d(2006,22): Error: 
template core.atomic.atomicOp cannot deduce function from argument types 
!("+=")(shared(uint), int), candidates are:

And then it just abruptly ends there.

I'm not sure why all these errors come out. Looking at the 
code, it seems to have nothing to do with my code. Once I fix 
my code errors (which are legitimate errors that I made), then 
these mysteriously go away. I'm not calling any of these 
functions that it's spitting out.


Why are these being triggered? Why do they all of a sudden go 
away? Does anyone else see this? Is it specifically something 
with vibe-core? Is it something to do with dub?





This is a regression caused by 
https://github.com/dlang/dmd/pull/10711

Re: Porting D to custom OS

[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 have 
to implement. Also, what happens if you only have partial 
support, for example networking is completely left out.


Will there be a future improvement of this so that OS specific 
support can be moved to separate files and selected on module 
level instead? For example.


void DSpecificLibraryFunction(...)
{
OSDependentLibraryFunction(...)
}

so that there are predefined OS specific functions that are 
selected on module level. Also version() switches where 
everything is consolidated into one file makes it more 
difficult to merge.


Do we have any guide for OS porting?


Best place to start would be without druntime at all, just a 
minimal object module, and extern(C) main, then work your way up, 
introducing each module one at a time to make sure that it all 
works.


There are a few core components that you need to port in order to 
get things working, or at least, you need to isolate and verify 
that it works, as if they don't then you'll get some very hard to 
debug issues.


The two main ones to pay close attention to are rt.sections and 
core.thread.  If exception handling is not dwarf-based, then 
you'll have to implement your own rt.deh too.

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

[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 branch gdc-5 into gdc-4.9

of branch gdc-4.9 on top of gcc-4.9.4 and got this error:

/bin/sh ../libtool --tag=D   --mode=compile 
/scratch/mockbuild1/bld-4.9.4/gcc-objdir/./gcc/gdc 
-B/scratch/mockbuild1/bld-4.9.4/gcc-objdir/./gcc/ 
-B/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/bin/ 
-B/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/lib/ -isystem 
/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/include -isystem 
/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/sys-include -O2 
-g  -nostdinc -pipe -Wno-deprecated -I 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/src -I 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/libdruntime 
-I ../libdruntime -I . -c -o std/net/curl.lo 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/src/std/net/curl.d
libtool: compile:  
/scratch/mockbuild1/bld-4.9.4/gcc-objdir/./gcc/gdc 
-B/scratch/mockbuild1/bld-4.9.4/gcc-objdir/./gcc/ 
-B/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/bin/ 
-B/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/lib/ -isystem 
/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/include -isystem 
/scratch/gcc-4.9.4/x86_64-unknown-linux-gnu/sys-include -O2 -g 
-nostdinc -pipe -Wno-deprecated -I 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/src -I 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/libdruntime 
-I ../libdruntime -I . -c 
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/src/std/net/curl.d  -fPIC -fversion=Shared -o std/net/.libs/curl.o

/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libphobos/src/std/math.d:8040:47: 
internal compiler error: Speicherzugriffsfehler
 return cast(Unqual!T) (T(1) << bsr(val) + type);
   ^
0x9e3b0f crash_signal
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/toplev.c:337
0xeb7af0 htab_hash_string
   
/scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/libiberty/hashtab.c:839

0x7bc0f7 external_ref_hasher::hash(external_ref const*)
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:7510
0x7bc0f7 hash_tablexcallocator>::find_slot(external_ref const*, insert_option)

   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/hash-table.h:505
0x7bc0f7 lookup_external_ref
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:7538
0x7bc19d optimize_external_refs_1
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:7576
0x7bc1c8 optimize_external_refs_1
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:7580
0x7bc5ed optimize_external_refs
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:7630
0x7bc9a5 output_comp_unit
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:8816
0x7d7319 dwarf2out_finish
   /scratch/mockbuild1/bld-4.9.4/gcc-4.9.4/gcc/dwarf2out.c:24301
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Is GCC 4.9 still maintained?



No, there is no man power nor incentive to maintain any prior 
versions of gcc where D is not an official frontend.


That means only gcc-9, and all future versions that will follow 
for will receive bug fixes for as long as they are supported in 
GCC's release cycle.

Re: Alignment of struct containing SIMD field - GDC

[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);
static assert(vec_struct.field.offsetof == 64);


With explicit align(32), it works:
https://godbolt.org/g/3GjOHW

- Johan


Well obviously, because it adheres to explicit alignment.  The 
compiler just has the wrong idea of how default alignment should 
work.


Raised bug here, and I'm raising a PR now also. 
https://issues.dlang.org/show_bug.cgi?id=17237

Re: Alignment of struct containing SIMD field - GDC

[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 'field' correct.


Does D automatically propagate the alignment restrictions on 
the field to the allocation of static structs or structs on the 
stack?


In this case:

struct vec_struct {
bool b2;
struct {
alias field this;
bool b;
int8 field;
}
}
it appears that the offset to 'field' is no longer aligned 
correctly - offset is 40 bytes in GDC. I don't suppose the 
compiler will use solely unaligned instructions? In any event, 
I could take the address of field and then pass that to someone 
expecting to pick up something with guaranteed correct 
alignment, if I have understood the D docs.




Yeah, it looks like the semantic analysis pass is defeating us 
here.  It's adding the anonymous struct offset to the aligned 
field, ignoring completely the original alignment.


Or... the anonymous struct alignment != largest field alignment, 
which probably is the more likely scenario.


Please raise a bug against DMD.

Simple test case would be:

struct vec_struct {
bool b2;
struct {
bool b;
int8 field;
}
}

static assert(vec_struct.b.offsetof == 32);
static assert(vec_struct.field.offsetof == 64);




Noob q: I notice that the GDC opcodes look a bit odd, for 
example the compiler generates a 256-bit unaligned fetch 
followed by an aligned binary operation (I think), eg a movdqu 
followed by a vpaddd r, ymm ptr blah - is the latter 
aligned-only? Apologies if I have got this wrong, need to read 
up. Would someone sanity-check me?


The x86 allows unaligned loads.  But if this is referencing the 
above data structure, you shouldn't be seeing this if the fields 
were correctly aligned.

Re: union alignment

[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 bytes on both x86 and 
x86_64.
The field align is worked out differently, something to the 
effect of:


uint fieldalignof(T)()
{
  version (X86_64)
return T.alignof;
  else version (X86)
  {
static if (isIntegral!T || is(T == double) || is(T == 
cdouble))

  return min(4, T.alignof);
else
  return T.alignof;
  }
}

static assert(ulong.alignof == 8);
static assert(double.alignof == 8);
static assert(fieldalignof!ulong == 4);
static assert(fieldalignof!double == 4);



DMD 32:
sizeof:  (8 >= 8) == true
alignof: (4 >= 4) == true

GDC 32:
sizeof:  (8 >= 8) == true
alignof: (4 >= 8) == false  <<= Bug?

LDC 32:
sizeof:  (8 >= 8) == true
alignof: (4 >= 4) == true


GDC is in the right, it's all other compilers that are wrong.  :-)

Iain.

Re: fromStringz problem with gdc

[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, std.c.stdlib;

int main () {
char* s;
s = cast(char*) malloc(2);
s[0] = 'a';
s[1] = '\0';
writeln(fromStringz(s));
return 0;
}


Compiling with DMD (works fine):
$ dmd testfsz.d

Compiling with GDC:
$ gdc testfsz.d -o testfsz
testfsz.d:8: error: undefined identifier fromStringz

It does the same thing on a friend's computer. I'm using GCC 
4.9.1 on Kubuntu 14.10.

Any idea where this comes from? Thanks in advance for your help!


fromStringz (in std.string) was introduced in D 2.066, gdc-4.9 
was shipped when 2.065 was released.


Iain.

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

[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 = 0u) is not callable using argument types (ulong, 
BlkAttr, TypeInfo_Array)
stack.d:110: error: function core.memory.GC.realloc (void* p, 
ulong sz, uint ba = 0u) is not callable using argument types 
(string*, ulong, BlkAttr, TypeInfo_Array)



These compile fine using DMD. Anybody know what the issue is 
here?


GDC is still on version 2.065.

Re: Interfacing via Java Native Interface

[Iain Buclaw]

On Wednesday, 16 October 2013 at 10:11:32 UTC, Andrew wrote:

Hello there!
I've decided to learn a bit of D, as I am currently Android 
Developer (mostly C++ <- JNI -> Java), I'm trying to create a D 
shared library which exports function (with extern (C)) for 
invocation from Java.
My .d file contains only a single function returning an int, 
.java calls this function several times.
This approach only works if d-function is trivial, e.g. it's 
not using any D functionality (I believe that it is related to 
GC and memory allocation).
For example, if my d-function just returns some constant 
integer, java side receives it. core.stdc.stdio also works and 
allows console output, but it's not the case with 
std.stdio.writeln and similar functions.
If I use any d-specific functions my program crashes while 
calling native code with some weird message like following:

"Invalid memory access of location 0x0 rip=addr".

It seems like D is not initialized at all, maybe there is some 
internal function like dinit() which I can call in order to 
activate everything?


Thanks.



JNI requires (to some degree) compiler support.  This could be 
done in gdc as backend support is there because of g++ JNI 
interface to gcj. But it would be some magic module or change to 
the language to add the Java types to the language.


Regards
Iain.

Re: License of RosettaCode examples (for bearophile:-)

[Iain Buclaw]

On Tuesday, 17 September 2013 at 11:04:13 UTC, Joseph Rushton 
Wakeling wrote:
This message is especially for bearophile, but applies to 
anyone posting examples on RosettaCode :-)


Can I ask you to clarify your licensing intentions for these 
examples?  By default all on RosettaCode is GNU Free 
Documentation License, which does not really play in a friendly 
way with ... just about any actual software license.


I imagine that all these examples were posted with the 
intention that they be used by others, but the default 
RosettaCode situation makes that impossible without direct 
permission.  So ... I'm asking. :-)




An example of what the situation is using GNU FDL - last time I 
checked material under the GNU FDL could not be put into GPL code 
and GPL code could not be put into a GNU FDL manual.  So watch 
out! :-)



Regards
Iain.

Re: Should it be a compile time error?

[Iain Buclaw]

On Wednesday, 19 June 2013 at 11:33:43 UTC, deed wrote:

The following compiles and crashes with DMD 2.063.
Should this be a compile time error?


class A
{
int _var;



/* SNIP */


int var() @property
{
return var;
}


Isn't the problem in this property function?  (Shouldn't it 
return _var :o)

Re: Segfault on simple program?

[Iain Buclaw]

On Saturday, 1 June 2013 at 10:11:35 UTC, Ali Çehreli wrote:

On 06/01/2013 01:34 AM, Shriramana Sharma wrote:

> All programs compiled by *DMD* produce a segfault. Programs
compiled
> by GDC work just fine.

It is likely that GDC is from the D1 era.



Not that package,  it's an old D2 release, circa 2.046. and even 
then it has a different library name (libgphobos.a) and the 
module headers are installed in a separate directory from dmd.

Re: and/or/not/xor operators

[Iain Buclaw]

On Thursday, 30 May 2013 at 16:18:44 UTC, Shriramana Sharma wrote:
Hello. I have always loved the readability of C++'s 
and/or/not/xor
word-like logical operators but It doesn't seem to be available 
in D.

Isn't this possible in D? I tried doing:



No, it isn't available... Thank goodness! :)

Re: Import Canon Camcorder AVCHD/MOV files to FCP with Mac Camcorder video converter

[Iain Buclaw]

On Wednesday, 22 May 2013 at 07:10:38 UTC, daisy520 wrote:

Import Canon Camcorder AVCHD/MOV files to FCP with Mac Camcorder
video converter

As a great non-linear video editing application, Final Cut Pro
has gained the favor of different people, from video hobbyists,
independent filmmakers to film and television editors. Final Cut
Pro provides non-linear, non-destructive editing of any 
QuickTime

compatible video format including DV, HDV, P2 MXF (DVCProHD),
XDCAM, and 2K film formats. Seems powerful enough? Even so, 
users

always encounter troubles when importing clips shot by different
cameras or camcorders, like Canon Vixia AVCHD, etc. In that way,
you have to consider transferring Canon Camcorder videos to FCP
compatible file types before importing, such as Apple ProRes
, Apple ProRes 422 (HQ), Apple ProRes 422,Apple ProRes 422
(LT), and Apple ProRes 422 (Proxy).
Now that we’ve talked about importing, I’d like to say something
different between Final Cut Pro 7 and the newest Final Cut Pro 
X.


Three ways are available for importing.
1. Importing from File-Based Cameras
2. Importing from FireWire Cameras and Decks
3. Importing Files - You can import files into Final Cut Pro X 
by

choosing Import > Files or by dragging files directly into the
Event Library. You don’t need to specify whether you’re 
importing

an individual file or a folder, as you do in Final Cut Pro 7.

Understanding the similarities and differences between Final Cut
Pro 7 and Final Cut Pro X will allow you to work faster than 
ever

with this new breakthrough application.

Back to the point, if you have troubles while importing 
different

Canon Camcorder videos to FCP, what to do? As we’ve mentioned at
the beginning, you have to consider converting Canon avchd/mov
footage to FCP workable format before importing. Indeed, there
are numbers of Canon video converter software in the market.
Choosing a good converter or a bad one will decide the quality 
of

your editing material, so it’s serious. Aunsoft Canon Camcorder
video converter for Mac will never let you down. It not only
provides expert format preset for Final Cut Pro, but also offers
profiles for other commonly-used video editing programs running
on Mac OS X, including iMovie, Final Cut Express, Avid Media
Composer, Adobe Premiere, and Sony Vegas. More than that, if you
wanna cut some Canon footage for watching on iPad, iPhone, Apple
TV, iTouch, Aunsoft Canon footage converter will also help you
realize the goal.

To encode Canon recordings to FCP for editing, three steps are
enough.
Step 1: Import Canon footage to Aunsoft Canon video converter 
for

Mac software.
Step 2: Select output format for FCP (X).
Step 3: Convert Canon footage to FCP compatible format.

Additional Tips - with Aunsoft Mac Canon AVCHD/MOV to FCP
Converter , you can do more:
- convert Canon AVCHD files to FCP editable format
- transfer Canon EOS DSLR H.264 MOV for Final Cut Pro
- transcode Canon MXF to QT MOV, Apple ProRes, AIC, DNxHD, etc.
- downsize 1080p Canon footage to 720p



This information has changed my life!


...



Or not...

Re: Compiler should error when goto over initialization?

[Iain Buclaw]

On Sunday, 16 September 2012 at 18:20:49 UTC, Jesse Phillips 
wrote:
I'm thinking I this is supposed to be a compiler error and I 
should report as a bug:


"It is illegal for a GotoStatement to be used to skip 
initializations."


void main() {
goto b;
int num = 5;
b:
num = 7;
}



Has not been implemented yet. :-)

I'm sure there is already a ticket open for it.

Regards
Iain

Re: D with gmp via swig

[Iain Buclaw]

== Quote from Oliver (oliver.ruebenkoe...@web.de)'s article
> Hello I am trying to get to a gmp interface for D2. I have some trouble to get
> that to work, however. Perhaps someone has an idea what I am doing wrong. I
> must admit I am not sure this is a D issue or a swig issue or something else.
> The interface file for swig
> cat gmpd.i
> %module gmpd
> %{
> #include "gmp.h"
> %}
> %include "gmp.h"
> A main with a call to gmpd
> cat main.d
> import std.stdio;
> import gmpd;
> void main() {
> writeln("Hello");
> }
> This is what I do then:
> /usr/local/swig-204/bin/swig -I/usr/include/ -d -d2 gmpd.i
> /opt/usr/local/bin/gdc -c main.d
> /opt/usr/local/bin/gdc -c gmpd.d
> /opt/usr/local/bin/gdc -c gmpd_im.d
> /opt/usr/local/bin/gdc -c gmpd_wrap.c
> /opt/usr/local/bin/gdc main.o -oa.out gmpd.o gmpd_im.o gmpd_wrap.o -lgmp
> I get messages of the type:
> /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
> __gmp_set_memory_functions: TLS definition in gmpd_im.o section .tbss
> mismatches non-TLS reference in gmpd_wrap.o
> gmpd_wrap.o: could not read symbols: Bad value
> collect2: ld returned 1 exit status

This will be a bug in swig.  Whatever storage class it is setting
__gmp_set_memory_functions, it is wrong (I assume it should be defining it as
__gshared).

Regards
Iain

Re: Problem with using && as shorthand for if

[Iain Buclaw]

== Quote from Ersin Er (ersin...@gmail.com)'s article
> Hi,
> The following code compiles and outputs "1 = 1" as expected:
> 1 == 1 && writeln("1 = 1");
> However, the following code fails to compile (although it should not):
> 1 == 2 && writeln("1 = 2");
> The error is as follows:
> Error: integral constant must be scalar type, not void
> What I expect that the second code should also compile and output nothing when
executed.
> Am I missing something?
> Thanks.

Because you are dealing with literals here, it's best to assume the compiler
will try to evaluate and compile down the code you write.

The first example you give will be optimized down to just

writeln("1 = 1");

Whilst your second example is simply

   false;


Regards