Add ImportC compiler to dmd
Walter Bright
newshound2 at digitalmars.com
Fri May 14 05:27:27 UTC 2021
On 5/13/2021 2:04 PM, Iain Buclaw wrote:
> Well, either one of, or two things will happen:
>
> 1. People will raise bugs against dmd because `gdc foo.c` will be able to
> compile more code than dmd (and do preprocessing).
>
> 2. People will raise bugs against gdc because `gdc -finline foo.c bar.d` doesn't
> inline C functions into bar.
>
> I meant conflicts will happen if I change the current behavior so make it so the
> D compiler handles C sources too i.e: `d21 bar.d foo.c -o bar.o`.
Understood.
It's pretty clear that ImportC is not going to be an exact clone of gcc. I've
been looking over the __attribute__ documentation, and there doesn't even seem
to be a proper grammar for it.
https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax
There's some wishy-washy wording:
"Where an attribute specifier is applied to a parameter declared as a function
or an array, it should apply to the function or array rather than the pointer to
which the parameter is implicitly converted, but this is not yet correctly
implemented."
"In some other cases, attribute specifiers are permitted by this grammar but not
yet supported by the compiler."
"At present, ..."
"An attribute specifier list may, in future, be permitted ..."
"at present this is not implemented and they are ignored"
"some laxity is allowed in the placing of attributes"
which is discouraging. There are the other extensions, too.
Ironically, the one gcc extension ImportC can support fully is inline assembler
:-) as you've already seen to that!
The plan is to do as few gcc C extensions as practical.
As for the user having options, that's why we have multiple D compilers. ImportC
isn't part of the D language, and so differing flavors of C support is within
reason.
More information about the Digitalmars-d
mailing list