This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ISO_C_BINDING patch commited to fortran-experiments branch

   So is the main reason that the ISO_C_BINDING required its own
branch that its formatting wouldn't be accepted by gcc rules?

There are many reasons for that choice, which I'll explain below. The decision itself was discussed a few times on IRC, mainly with Steve and Paul. If the general opinion here is that it's the wrong way to proceed, it's never too late to do things differently.

Among the reasons for stabilizing the patch on a branch:

 - It's huge; the diff Christopher sent me is 11k lines, touching 31
different files (testcases excluded), including 15 of the 41 front-end
.c files. This means that it's gonna be long/hard to test extensively,
long/hard to review and so on.

 - It's huge, and it's already late in the 4.3 development cycle: a
branch helps getting more people working on it, especially as some of
us are running low on idle time to contribute to gfortran [Paul has
announced his intention to slow down gfortran work, Steve said he
would have low activity for some time and I'll (although silently, for
now on) will do the same until next summer (PhD to finish working on
and thesis to write).]

 - Developing large, invasive new features for inclusion into GCC is
usually done on branches, so why not follow the common pratice here?

 - This patch has been designed and written by someone with little
experience of the front-end (this is not meant as a criticism; it
would more be a "hats off" comment since Christopher did so much work
in areas unknown to him beforehand), so we might as well help him as
much as we can

 - From what I saw of the code, it could benefit (and has already
benefitted before I commited it to the branch) from reorganizations in
some areas, to reduce code duplication and change fewer code
structures to minimize risks.

 - It has formatting issues, and by this I don't only mean
whitespace/indentation problems: it's also documentation style,
functions and variables naming, etc.

I hope this helps understanding the reasons for the decision. Of
course, comments are welcome!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]