On 16 November 2015 at 09:30, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
Am Mon, 16 Nov 2015 08:49:57 +0100
schrieb Iain Buclaw via Digitalmars-d
<digitalmars-d@puremagic.com>:

> There should be ways to catch ABI changes in the build or test process.
> Maybe I'm misremembering something though. :-)
>
> There should be a degree of ABI compatibility between releases for plain
> static functions - assuming that we add no more properties to the
> language.  That leaves what breaks the most in moving to a new version are
> template instantiations, no?

Frankly I have no idea what level of testing is in place. :D
To be practical for package maintainers, we would need some
higher level common D ABI versioning scheme that includes
Phobos. Then I could start grouping libraries by architecture
and this ABI version instead of by compiler/FE version. But
let's take baby steps here and first get DMD to use DWARF EH.
Once we can dynamically link DMD<->GDC, DMD<->LDC, we can
think about a stable Dlang ABI in terms of EH, function
mangling, Phobos etc.

A good litmus test would be to take the C++ ABI tests in the D2 testsuite, and convert the C++ sources to D.  Build one with DMD and the other with GDC.  If something segfaults or goes wrong at runtime, then raise a bug about how DMD doesn't pass parameters correctly. ;-)

Besides, I'd worry more about how DMD keeps changing the names of runtime hooks to be able to do things GDC has done for years.  With Dwarf EH thrown into the mix, there's now three functions that handle throwing objects (GDC still only has one).  Not cool man!