Recent changes to GDC.

[Iain Buclaw]

On 16 January 2012 14:41, Artur Skawina <art.08.09 at gmail.com> wrote:
> On 01/15/12 23:34, Iain Buclaw wrote:
>> * Merged in the work Walter has done for __vector type support.  There are now newly available GCC builtins for vector operations via gcc.builtins module.
>
> Allowing !=128 bits wide types would be just a matter of removing the frontend
> restrictions, right? (i didn't look at the latest commits, maybe you already did
> that)
> As the vector ops often will need to be wrapped, lack of cross module function
> inlining is a problem.
>

If you want cross-module inlining, compile all sources in one command.

gdc file1.d file2.d -o myapp



>> * GDC's default calling convention has now been switched back to that of the default for the target platform.
>
> Hmm. You just invented a new ABI. "extern(D)" will mean different things to
> different compilers on the same platform. Only makes sense if you're sure to
> win the ABI war, and the other party to practically disappear.

I did not invent an ABI.  extern(D) is only defined for the x86
platform - and it is no secret that only DMD adheres to it.


> This new ABI still isn't compatible with the default "C/C++" one, because of
> name mangling. (could it be made, at least partially, C++ compatible?)
> As you still cannot easily call D code from C, without the equivalent of
> "extern(D)", why not default to a more sane calling conventions, such as
> regparm on 32-bit x86?

The default calling convention is cdecl - this is directly ABI
compatible with C and C++ code with the exception to name mangling
requiring special treatment.

eg:

extern "C" int _Dmain(struct string args);


> GCC made a mistake years ago to not mangle the names when using a nonstd
> convention (eg by prepending '@' like some other compilers did) which
> resulted in this feature being unusable, other than for application-internal
> functions, as calling the wrong version will silently build and link, only to
> blow up at runtime; you also cannot place both versions in a library etc.
> Hence "fixing" this had to wait for a new architecture (x86_64) and whole
> program optimizations/LTO, which can figure out automatically when it's safe
> to switch to a more efficient convention.
>

What makes you think changing the calling convention will turn off
name mangling?


>> The D_InlineAsm family of version identifiers are now turned off by default as we no longer pretend to follow DMD's calling convention. For those who want to turn on D_InlineAsm(_X86/_x86_64) there is a -fd-inline-asm compiler switch.
>
> Why is it a compiler option? Ie is it safe to turn it on (why optional then?)
> or will it result in wrong code being generated (why have the option then?).
> D_InlineAsm allowed things like the cpuid code to work, will every asm{} now
> need to be rewritten, or could a safe subset of the "D" asms be reused?
>

All Inline Asm code in Druntime and Phobos is written with the DMD
calling convention in mind, so ie: when one of the naked functions in
std.math pops the stack when returning a float, the caller won't clean
this in GDC generated code.  Other than that, it works perfectly well
(tm).


>> * GDC will emit the GNU_InlineAsm version identifier to tell user code that we support GNU Extended Inline Assembly.
>
> BTW, a identifier, which is set for *both* x86 and x86_64 would be good - because
> of how D's version() works and the fact that on those platforms the asm code will
> often be identical.
>
>> * All patches to GCC proper have now been removed, GDC can now build applications without relying on changes to the backend, with the exception of naked functions.
>>
>> * "naked" has now been implemented now as a function attribute of the x86 platform.  It is applied to all naked functions, and implies noinline and noclone.
>
> I've never really understood the reason for "naked". Custom prologue and epilogue
> could be useful sometimes, but turning the compiler into an assembler?... You can
> already write "naked" asm functions in gcc - with asm()s outside of functions
> plus some as(1) section push/pop magic, iirc.
> Now you've removed the D builtin assembler, but decided to introduce "naked".
> Is it really necessary? There are no back-compat concerns...
> How does naked work will the various gcc features the modify prologue (profiling,
> stack usage checking, forced stack aligment etc)?
>

I have not removed the D builtin assembler. I have just removed
D_InlineAsm version identifers.  GDC's "naked" function support was
originally a (pretty bad) hack in GCC.  It is now implemented cleanly
as a function attribute, and does not affect the code generation of
other frontends.


>> * D version 2 is now the default compiler to build.
>>
>>
>> I will get round to putting up a roadmap to GCC-4.8 sometime this week, and I invite everyone interested in making this happen to get together and help progress this. :)
>
> What's the plan wrt druntime and phobos? It would be good if both could stay
> completely out of gcc, just like libc. Would make contributions significantly
> easier (no copyright assignment...) and maybe even a common version could
> emerge.
>
> artur

I have no plans to remove libphobos or druntime from the compiler.  I
will check licensing, but there should be no issues with including it.



-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';