This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Output from C2F
Sounds good to me. :-)
On Sat, Dec 9, 2017 at 1:22 PM Paul Richard Thomas <
paul.richard.thomas@gmail.com> wrote:
> Hi Fritz,
>
> Thanks for the rapid reply. I think that, in the circumstances, I will
> adjust c2f to produce structures, when there are map/union components.
> It's rather more than I intended to do with it but the other snags
> will take a comparable amount of effort to put right, I fear. I intend
> to take it to the point where it will produce fortran code that
> requires a minimum of manual correction. I will leave it to somebody
> else to introduce class conversions :-)
>
> Cheers
>
> Paul
>
>
> On 9 December 2017 at 18:11, Fritz Reese <fritzoreese@gmail.com> wrote:
> > Paul,
> >
> > Nice work! I am happy to hear my extension support has come in handy.
> >
> > There were a number of reasons I chose to avoid messing with unions
> inside
> > derived types. Because derived types support many more features than
> > STRUCTURES it would have complicated the implementation. Most notably
> there
> > are many functions which would have needed to check for and handle
> (usually
> > ignore) union components which are irrelevant for structures. Another
> > example is that STRUCTUREs function like TYPE with the SEQUENCE attribute
> > which is necessary for unions- should I imply SEQUENCE if I see a union
> > inside a derived type? Should I fail unless SEQUENCE is given? Aside from
> > simplicity, in my initial patches I also tried to affect as few existing
> > code paths in the FE as possible under the assumption that would increase
> > receptivity by the maintainers.
> >
> > The only DEC compiler I have access to is ifort 11. Normally I find the
> > answers to questions such as those posed above either by poring over what
> > little ifort documentation I can find, or by monkey testing my ifort on
> > various inputs. IIRC my ifort actually complained about unions inside
> > derived types, for which I breathed a sigh of relief and said to myself,
> > “hopefully nobody will need this”.
> >
> > If you think it is important I can probably patch it in now that I have a
> > better understanding of the Fortran FE. But that may not come until
> February
> > as I am currently on a release timeline due mid-January for a project at
> > work, while dealing with holiday syndrome. And I have a few tricky PRs
> for
> > -finit-derived to solve first.
> >
> > - Fritz
> >
> >
> > On Sat, Dec 9, 2017, 07:38 Paul Richard Thomas
> > <paul.richard.thomas@gmail.com> wrote:
> >>
> >> Hi Fritz,
> >>
> >> I was triggered by a thread on clf to get c2f to compile and run with
> >> gfortran, rather than CVF. It was a more or less straightforward
> >> operation, largely due to your efforts to implement -fdec, and the
> >> replacement of some dflib calls to runqq(...) and commitqq(...) with
> >> system(...) and flush(...).
> >>
> >> It now produces output from the supplied debug.c but the resulting
> >> debug.f90 does not compile completely with gfortran. Notable among the
> >> failures are:
> >>
> >> union test
> >> {
> >> int x;
> >> char y;
> >> };
> >> union test a;
> >>
> >> translating to:
> >> TYPE :: TEST
> >> UNION
> >> MAP
> >> INTEGER :: x
> >> END MAP
> >> MAP
> >> CHARACTER :: y
> >> END MAP
> >> END UNION
> >> END TYPE
> >> TYPE (TEST) :: a
> >>
> >> and
> >> typedef struct
> >> {
> >> int a;
> >> float b;
> >> union
> >> {
> >> int c;
> >> float d;
> >> } u1;
> >> struct
> >> {
> >> int e;
> >> float f;
> >> } s1;
> >> double z;
> >> } Bigtype;
> >>
> >> translating to:
> >> TYPE :: U1_U
> >> UNION
> >> MAP
> >> INTEGER :: c
> >> END MAP
> >> MAP
> >> REAL(4) :: d
> >> END MAP
> >> END UNION
> >> END TYPE
> >> TYPE :: S1_T
> >> INTEGER :: e
> >> REAL(4) :: f
> >> END TYPE
> >> TYPE :: BIGTYPE_T
> >> INTEGER :: a
> >> REAL(4) :: b
> >> TYPE (U1_U) :: u1
> >> TYPE (S1_T) :: s1
> >> REAL(8) :: z
> >> END TYPE
> >>
> >> I presume that these must have compiled OK on CVF and I was wondering
> >> why you didn't implement derived types hosting union/map? Obviously, I
> >> could modify c2f to produce structures rather than derived types but
> >> the backward compatability of gfortran with -fdec would be enganced if
> >> the above versions were allowed.
> >>
> >> Cheers
> >>
> >> Paul
> >>
> >> PS: Other snafus are:
> >> (i) Cray pointers clashing with a later declaration of their type;
> >> (ii) Error: CRAY POINTEE attribute conflicts with TARGET attribute at
> (1);
> >> (iii) Warning: Cray pointer at (1) has 4 bytes of precision; memory
> >> addresses require 8 bytes;
> >> (iv) Passing integer(4) to integer(2);
> >> (v) Some out of bounds array references;
> >> (vi) Operands of comparison operator ‘>’ at (1) are
> LOGICAL(4)/INTEGER(4);
> >> (vii) Error: Assumed size array at (1) must be a dummy argument; and
> >> (viii) Some missing explicit interfaces, generated by the need to use
> >> -fno-whole-file to overcome some deliberate interface mismatches
> >> (character, dimension(len) => character(len) mostly).
> >>
> >> All in all though, it is not too bad for the conversion of 2022 lines
> >> of C into 3373 lines of fortran, including a lot of c2f supplied
> >> comment lines. The porblems could be fixed by hand but, having
> >> started, I intend to complete the job
>
>
>
> --
> "If you can't explain it simply, you don't understand it well enough"
> - Albert Einstein
>