Built latest gcc4-8-based gdc (fdf0c614) today; immediately ran into
this:
Which is much more reasonable, and shouldn't require such hacks.
I thought that inlining /templated/ functions across modules already
worked; is this a different problem, and, more importantly, is it
fixable?
artur

Built latest gcc4-8-based gdc (fdf0c614) today; immediately ran into
this:
Which is much more reasonable, and shouldn't require such hacks.
I thought that inlining /templated/ functions across modules already
worked; is this a different problem, and, more importantly, is it
fixable?

Built latest gcc4-8-based gdc (fdf0c614) today; immediately ran into
this:
Which is much more reasonable, and shouldn't require such hacks.
I thought that inlining /templated/ functions across modules already
worked; is this a different problem, and, more importantly, is it
fixable?

Built latest gcc4-8-based gdc (fdf0c614) today; immediately ran into
this:
Which is much more reasonable, and shouldn't require such hacks.
I thought that inlining /templated/ functions across modules already
worked; is this a different problem, and, more importantly, is it
fixable?

Built latest gcc4-8-based gdc (fdf0c614) today; immediately ran into
this:
Which is much more reasonable, and shouldn't require such hacks.
I thought that inlining /templated/ functions across modules already
worked; is this a different problem, and, more importantly, is it
fixable?

Reason for no inline is "mismatched arguments" - which means that the
caller and callee disagree on the arguments to pass to the function.
The fix is to make sure that caller and callee arguments match when
generating the function on both sides. We could prevent this from
recurring by putting in an assert in the codegen.

Reason for no inline is "mismatched arguments" - which means that the
caller and callee disagree on the arguments to pass to the function.
The fix is to make sure that caller and callee arguments match when
generating the function on both sides. We could prevent this from
recurring by putting in an assert in the codegen.

Root cause is that const(char)[] is a distinct type compared to char[]
so I think we need to make const(char)[] a variant of char[].
We could use build_variant_type_copy and then modify the copy
to use the correct basetype. Here's a proof of concept, could you finish
this Iain?
(We should probably check all types which have a 'next' type if a
similar change makes sense for these)

I've had another thought for a while now that involves not constifying 'in'
parameters, but at the same time not loosing its guarantee.

I've had another thought for a while now that involves not
constifying 'in' parameters, but at the same time not loosing its
guarantee.

But we'd want this to work/inline nevertheless, right?:
------------
void test(const(char)[] a)
{
}
char[] abc;
test(abc);
------------
Then we still need to tell GCC that const(char)[] is a variant of
char[] or it won't inline.

But we'd want this to work/inline nevertheless, right?:
------------
void test(const(char)[] a)
{
}
char[] abc;
test(abc);
------------
Then we still need to tell GCC that const(char)[] is a variant of
char[] or it won't inline.

Can you just strip all const/immutable/etc when the type is passed to the
backend?

But we'd want this to work/inline nevertheless, right?:
------------
void test(const(char)[] a)
{
}
char[] abc;
test(abc);
------------
Then we still need to tell GCC that const(char)[] is a variant of
char[] or it won't inline.

Can you just strip all const/immutable/etc when the type is passed to
the backend?

This would impact debug info which is also emitted by the backend. GCC
supports 'variants' of types which means only different qualifiers but
the same apart from type qualifiers. We just need to set the variant
information correctly (e.g. const(char)[] should be recognized as a
variant of char[])

But we'd want this to work/inline nevertheless, right?:
------------
void test(const(char)[] a)
{
}
char[] abc;
test(abc);
------------
Then we still need to tell GCC that const(char)[] is a variant of
char[] or it won't inline.

Can you just strip all const/immutable/etc when the type is passed to
the backend?

This would impact debug info which is also emitted by the backend. GCC
supports 'variants' of types which means only different qualifiers but
the same apart from type qualifiers. We just need to set the variant
information correctly (e.g. const(char)[] should be recognized as a
variant of char[])

Right, and not having const applied to the type means that gcc might miss
an optimisation opportunity.
In this case however I think that parameters declared in should not be
mapped to C-style 'const'. The 'in' keyword is close, but something other.

But we'd want this to work/inline nevertheless, right?:
------------
void test(const(char)[] a)
{
}
char[] abc;
test(abc);
------------
Then we still need to tell GCC that const(char)[] is a variant of
char[] or it won't inline.

Can you just strip all const/immutable/etc when the type is passed to
the backend?

This would impact debug info which is also emitted by the backend. GCC
supports 'variants' of types which means only different qualifiers but
the same apart from type qualifiers. We just need to set the variant
information correctly (e.g. const(char)[] should be recognized as a
variant of char[])

Right, and not having const applied to the type means that gcc might miss

an optimisation opportunity.

In this case however I think that parameters declared in should not be

mapped to C-style 'const'. The 'in' keyword is close, but something other.
FORTRAN for instance has intent attributes.
---
intent(in) - yes, pass by value, so changes of this are not reflected in
outside code.
intent(out) - pass somehow by reference, in fact a return argument
intent(inout) - pass by reference, normal in/out parameter.
---
These are interesting concepts that allows more aggressive optimisation
than using C/C++ const/ref type variants. I think gdc should go down this
route, but I've never experimented too much round this area.

But we'd want this to work/inline nevertheless, right?:
------------
void test(const(char)[] a)
{
}
char[] abc;
test(abc);
------------
Then we still need to tell GCC that const(char)[] is a variant of
char[] or it won't inline.

Can you just strip all const/immutable/etc when the type is passed to
the backend?

This would impact debug info which is also emitted by the backend. GCC
supports 'variants' of types which means only different qualifiers but
the same apart from type qualifiers. We just need to set the variant
information correctly (e.g. const(char)[] should be recognized as a
variant of char[])

Right, and not having const applied to the type means that gcc might miss
an optimisation opportunity.
In this case however I think that parameters declared in should not be
mapped to C-style 'const'. The 'in' keyword is close, but something other.

FORTRAN for instance has intent attributes.
---
intent(in) - yes, pass by value, so changes of this are not reflected in
outside code.
intent(out) - pass somehow by reference, in fact a return argument
intent(inout) - pass by reference, normal in/out parameter.
---
These are interesting concepts that allows more aggressive optimisation than
using C/C++ const/ref type variants. I think gdc should go down this route,
but I've never experimented too much round this area.

See gimple.c: gimple_call_arg_flags for the middle-end detection and
the implementation is roughly:
EAF_UNUSED: Unused
EAF_NOCLOBBER: Read-only
EAF_NOESCAPE: Not escaping
EAF_DIRECT: Only once dereferenced (*p, not **p)
The 'in' attribute could be mapped to 'r', meaning read-only and not escaping.
Regards
Iain.

Root cause is that const(char)[] is a distinct type compared to
char[] so I think we need to make const(char)[] a variant of char[].
We could use build_variant_type_copy and then modify the copy
to use the correct basetype. Here's a proof of concept, could you
finish this Iain?
(We should probably check all types which have a 'next' type if a
similar change makes sense for these)

I've had another thought for a while now that involves not
constifying 'in' parameters, but at the same time not loosing its
guarantee.