Data representation question

Bill Schmidt wschmidt@linux.vnet.ibm.com
Wed Dec 4 20:01:00 GMT 2013


On Wed, 2013-12-04 at 20:51 +0100, FX wrote:
> > Since none of us here are really knowledgeable about Fortran, this is
> > just a follow-up query to see whether we should expect any problems from
> > this different choice of representation.  It seems clear that the use of
> > TRANSFER is extremely target-dependent, and that code making assumptions
> > about bit representations when using TRANSFER should expect some porting
> > problems.
> 
> I don’t expect you’ll have much trouble. The front-end code should be totally clean, i.e. it translates directly from the MPFR-represented values (obtained by parsing and front-end simplification passes) to the middle-end trees, without any assumptions about format. [1] The library is probably also safe, because we don’t manipulate the individual bits, we use libc functions instead.
> 
> I expect the testsuite might have a few more occurrences of bit-pattern comparison, though. I’ve looked on the gcc-testresults archive but couldn’t find test results for your target (powerpc64le), though!

OK, thanks!  Yes, the target is pretty new, and we aren't to the point
yet of having automatic testers posting to the testresults site.  But
this is the only failure of this sort that we ran into when running
through the testsuite, so that's good.

Thanks very much for the reassurance. :)

Bill

> 
> 
> FX
> 
> 
> [1] In fact, the only case that currently needs special handling is the IEEE extended double, in gfc_init_kinds(). But it’ll work whether you’re LE or BE.




More information about the Fortran mailing list