[PATCH] fortran: C++ support for generating C prototypes

[Janne Blomqvist]

On Wed, May 15, 2019 at 4:41 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> On Sun, May 12, 2019 at 12:47:04AM +0300, Janne Blomqvist wrote:
> > --- a/gcc/fortran/parse.c
> > +++ b/gcc/fortran/parse.c
> > @@ -6331,6 +6331,24 @@ done:
> >        }
> >
> >    /* Dump C prototypes.  */
> > +  if (flag_c_prototypes || flag_c_prototypes_external)
> > +    {
> > +      fprintf (stdout,
> > +            _("#include <stddef.h>\n"
> > +              "#ifdef __cplusplus\n"
> > +              "#include <complex>\n"
> > +              "#define FLOAT_COMPLEX std::complex<float>\n"
> > +              "#define DOUBLE_COMPLEX std::complex<double>\n"
> > +              "#define LONG_DOUBLE_COMPLEX std::complex<long double>\n"
> > +              "extern \"C\" {\n"
> > +              "#else\n"
> > +              "#define FLOAT_COMPLEX float _Complex\n"
> > +              "#define DOUBLE_COMPLEX double _Complex\n"
> > +              "#define LONG_DOUBLE_COMPLEX long double _Complex\n"
> > +              "#endif\n\n"));
>
> Two more things:
> 1) why the _() around the code snippet?  Do you expect translators
>    to translate the C snippets to something else or what?

Er, because originally I printed out these definitons as part of the
other fprintf call where a comment was printed, and when I moved it to
another location I forgot to remove the translation markers.

Committed r271261 and r271264 as obvious.

> 2) I don't think float _Complex is
>    passed the same as std::complex<float> and similar for others;
>    std::complex<float> is in libstdc++ a C++ class with with
>    __complex__ float as its sole non-static data member and with non-trivial
>    constructors; which means it is passed/returned via a hidden reference;
>    when the argument is actually FLOAT_COMPLEX * or FLOAT_COMPLEX &,
>    you except for aliasing don't have to care that much, but if
>    that complex argument has VALUE attribute in Fortran and so the
>    C prototype would be FLOAT_COMPLEX, then std::complex<float> is
>    passed in the end as std::complex<float> &, while float _Complex
>    the same as __complex__ float; and ditto for functions returning
>    complex

Ugh, I guess that's right. Any good way around it? Except print a
warning in the header that passing std::complex<> by value doesn't
work?

-- 
Janne Blomqvist