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