Re: Crash course?

[Russell Brennan <RussellJBrennan at gmail dot com>]

Great, I think you've given me a solid couple of weeks worth of work!
;)  I did mean to reply to all there, I'm just not used to
communicating via mailing lists (I will save my inquiries about the
continued merit of mailing lists for later...).  Your description was
very useful and makes total sense!  In some respects this may turn out
to be easier than I anticipated.

~Russell

On Fri, Feb 8, 2013 at 9:58 AM, Janus Weil <janus@gcc.gnu.org> wrote:
> Hi Russell,
>
> first lesson for working on gfortran: Public communication is
> preferable over private communication! I hope you don't mind if I
> reply to your private email publicly on the mailing list (in CC), and
> I encourage you to do likewise. Other people might be willing and able
> to contribute to the discussion.
>
>
>> Thanks for pointing me in the right direction!
>
> You're welcome.
>
>
>> I have checked out and built the gcc source.
>
> Good!
>
>
>> What workflow do you guys use to
>> edit/recompile/test? I added some garbage to parse.c and used 'make
>> fotran'(on a hunch) in the gcc dir, and found that I can do 'make
>> fortran.mostlyclean' but is there a better way?
>
> I usually just do a simple "make" (i.e. "make all") in the base dir,
> which rebuilds everything that is needed. Others might have different
> habits.
>
> Btw, for debugging purposes it can be useful to add e.g. CXXFLAGS="-g3 -O0"
>
>
>> I was actually thinking that STRUCTURE and RECORD might be best
>> handled by treating them as f95 TYPE decls under the hood, but since
>> it is feasible to write a script to convert STRUCTURE/RECORD to TYPE I
>> will defer that to another time.
>
> Well, "under the hood" they would certainly be treated the same as
> TYPE, since they provide the same functionality. Still, I do not think
> it's useful for gfortran to support this sort of "alternative" syntax.
> If there is a "standard" way to do it, one should stick to the
> standard!
>
>
>> Another thought that I had was to treat UNION/MAP as a basic form of a
>> C/C++ union of structures... not sure how portable the code from the c
>> compiler would be here but would it make sense to use that as a point
>> of reference?
>
> Maybe I'll start with a very rough overview of GCC's structure: There
> are several "front ends" for different languages (C, C++, Fortran,
> Java, Ada, ...), then there is a common "middle end" and finally there
> are several "back ends" for different architectures. The front ends
> parse the respective input source code and generate an internal
> representation of it, which is then converted to a common middle-end
> representation. In the end the respective back end takes the
> middle-end representation and generates the actual object code from
> it. (That's certainly a very schematic description, but it should be
> enough to give you the big picture.)
>
> Now, IIUC, UNION/MAP (as a Fortran extension) is completely analogous
> to (and compatible with) C unions. Since GCC supports the union
> concept for C, the middle-end is certainly able to handle (i.e.
> represent) it, and one basically just has to add support for the
> syntax in the Fortran front end and generate the right middle-end
> structures. (I hope this answers what you're asking for.)
>
> As noted before, my advice would be to start with the parsing of the
> syntax: Have a look at how gfortran parses other syntactical
> constructs (see decl.c and parse.c, mostly), and then try to do the
> parsing of the UNION and MAP statements. Since UNION and MAP will be
> inside a TYPE declaration, you should certainly understand how TYPE
> definitions are parsed first.
>
> Cheers,
> Janus
>
>
>
>> On Fri, Feb 8, 2013 at 7:35 AM, Janus Weil <janus@gcc.gnu.org> wrote:
>>>> I'm looking to try to add some functionality to the gfortran compiler,
>>>> namely support for the DEC extensions RECORD, STRUCTURE, UNION, and
>>>> MAP.
>>>
>>> Btw, I would advise against implementing the STRUCTURE and RECORD
>>> syntax, as described e.g. here:
>>>
>>> http://software.intel.com/sites/products/documentation/doclib/stdxe/2013/composerxe/compiler/fortran-mac/GUID-4BAEE9DF-1514-4EAC-9937-3CCE2F18C54E.htm#GUID-4BAEE9DF-1514-4EAC-9937-3CCE2F18C54E
>>>
>>> IIUC, they are identical to F95 TYPE declarations (and therefore easy
>>> to convert). Rather, I think you should focus on UNION/MAP, which have
>>> no counterpart in standard Fortran.
>>>
>>> Cheers,
>>> Janus