On Fri, 2009-06-26 at 12:52 -0700, Ian Lance Taylor wrote:
> Arnaud Charlet <char...@adacore.com> writes:
>
> >> Switching gnatbind to generate Ada if there's nothing against
> >> it might be a better solution since stage1 uses the system gnatbind, so
> >> a patch to current gnatbind will not help (unless we push it to branches
> >> and tell user to install a fairly recent gnatbind first).
> >
> > This does create a bootstrap incompatibility/issue indeed, interesting.
> > Yet another alternative would be to use a C compiler to compile the binder
> > generated file during bootstrap.
>
> Yes, I think that either compiling with a C compiler, or generating Ada
> bindings, would be the best approach here.
Switching gnatbind to generate Ada during bootstrap and with a mostly
mechanical patch adding "#ifdef __cplusplus / extern C" where needed to
honor matching "pragma Import/Export (C, xxx)" in Ada code I now get all
three stages and gnatlib to build successfully on the branch.
There was one other C/C++ compat issue: wrong code generated in
gcc/ada/gcc-interface/utils.c and Andrew Pinski suggested the solution
on IRC:
@@ -4861,7 +4861,7 @@
va_start (list, n);
for (i = 0; i < n; ++i)
{
- builtin_type a = va_arg (list, builtin_type);
+ builtin_type a = (builtin_type)va_arg (list, int);
t = builtin_types[a];
if (t == error_mark_node)
goto egress;
This was the only va_arg usage, may be we should apply it on trunk too
as the patched version is supposed to work for both C and C++.
For toplevel gnattools I have a link issue since the LINKER
variable used in the gcc subdir is not passed at toplevel, I'm currently
trying wether passing LINKER=$(CXX) will do but I'm not sure that we
really want here.
I will submit the gnatbind switch to Ada patch separately for review on
trunk after testing completes.
Hopefully there seem to be no major issue in having Ada working
on the gcc-in-cxx branch.
Sincerely,
Laurent
