This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fortran's C_CHAR type
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Mikael Morin <mikael dot morin at sfr dot fr>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Richard Biener <rguenther at suse dot de>, Joseph Myers <joseph at codesourcery dot com>, gcc-patches at gcc dot gnu dot org, burnus at net-b dot de
- Date: Thu, 11 Jun 2015 19:58:47 +0200
- Subject: Re: Fortran's C_CHAR type
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1506081354460 dot 25225 at digraph dot polyomino dot org dot uk> <alpine dot LSU dot 2 dot 11 dot 1506081608030 dot 30088 at zhemvz dot fhfr dot qr> <alpine dot DEB dot 2 dot 10 dot 1506081431250 dot 25225 at digraph dot polyomino dot org dot uk> <20150608144415 dot GA23542 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1506081650490 dot 30088 at zhemvz dot fhfr dot qr> <20150608150837 dot GC23542 at kam dot mff dot cuni dot cz> <20150608153132 dot GB17321 at kam dot mff dot cuni dot cz> <5578239D dot 4050504 at sfr dot fr> <20150610143803 dot GC60741 at kam dot mff dot cuni dot cz> <557864E5 dot 3020008 at sfr dot fr>
> I have had a look at the table and the text around, and first I should
> correct myself.
> C_CHAR is 1, C_SIGNED_CHAR is 1, and the default values for len= and
> kind= are 1 as well.
> So, even if CHARACTER(KIND=C_CHAR) is what should be used as it's not
> dependent on the implementation's default kind choice, it boils down to
> the same as CHARACTER(C_CHAR), namely CHARACTER(len=1, kind=1) actually.
Thanks for explanation - as I said I hardly wrote any Fortran code except
for these few testcases :))
>
>
> And about the line saying CHARACTER(KIND=C_CHAR) interoperable with char
> in table 15.2:
> You're right, while I would myself prefer to use an
> INTEGER(KIND=C_SIGNED_CHAR) type, CHARACTER(KIND=C_CHAR) should be
> supported as well.
> That means that char should be compatible with char[1], I think.
> You said there is no guarantee they are passed the same way?
With LTO we definitely don't consider the types compatible, so we produce bogus
warning. Things may work on TBAA side because it basically ignores arrays, but
I am not 100% sure - will double check.
For passing conventions, it is definitely not a requirement of C ABI to pass arrays
of size 1 and scalars same way. I think there are ABIs passing scalars in registers
and everything else in memory (PPC SYSV ABI?).
If we consider my testcase defined, I would suggest simply adding it to testsuite
and lets see if something breaks.
>
>
> > If you can look at the other c-bind testcases I produced, I would really appreachiate that.
> I have looked at:
> https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00693.html
> https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00713.html
> I saw nothing wrong with the tests.
> Avoiding character interoperability avoids most of the pain. ;-)
Hehe, quite on the contrary, I would say that both Richard and me had quite some pain from
the rest of interoperability rules, too ;))
Honza
>
> Mikael