This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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: [patch][fortran] Include coretypes.h in .c files, not in gfortran.h


On Sat, Jul 14, 2012 at 4:06 PM, Mikael Morin <mikael.morin@sfr.fr> wrote:
> On 14/07/2012 15:45, Steven Bosscher wrote:
>> On Sat, Jul 14, 2012 at 3:23 PM, Tobias Burnus <burnus@net-b.de> wrote:
>>> Steven Bosscher wrote:
>>>>
>>>> On Thu, Jul 12, 2012 at 11:29 AM, Tobias Burnus <burnus@net-b.de> wrote:
>>>>>
>>>>> On 07/07/2012 11:28 PM, Steven Bosscher wrote:
>>>>>>
>>>>>> I must say, I am surprised that gfortran.h includes coretypes.h. The
>>>>>> idea always was to try and keep the front end and the back end as much
>>>>>> separated as possible, and including coretypes.h in the most important
>>>>>> front-end header doesn't fit in that picture.
>
> Well it makes sense to me, actually.
> The frontend has internal structures to represent symbols, expressions
> etc, and it attaches the corresponding backend representations in those
> structures.  And the backend representation has type tree, so it needs
> this from coretypes.h:
>
> union tree_node;
> typedef union tree_node *tree;
>
> It's a black box type, as the type definition is not in coretypes.h (at
> least in my few days old trunk).  So the backend is kept separated from
> the frontend.  What's wrong with that?

Nothing per se, in GCC. But let's say someone wants to glue gfortran
to another back end, or make a stand-alone parser for a code checker,
then you wouldn't want to include coretypes.h. You'd want to just cut
off all trans-* files and use gfortran's internal data structures, or
perhaps the dumped version of it.

I don't see it as a big problem, though.


>>> If one now includes "tree.h" in gfortran.h, it fails because "tree.h"
>>> includes "vecir.h", which has at the top:
>>> #ifndef GCC_CORETYPES_H
>>> #error "vecir.h must be included after coretypes.h"
>>> #endif
>>>
> Silly question: why don't they just include coretypes.h here?

This is not a silly question at all, although arguably it should be.

There is no convention in GCC for including headers within headers.
Some headers include everything they need, others do not. For example,
my dumpfile.h patch from yesterday makes tree-pass.h include
dumpfile.h and timevar.h because tree-pass.h uses symbols from those
headers, but your vecir.h example shows that this header uses a
different approach (#error). In gfortran, gfortran.h is the One Header
To Rule Them All. What is done where seems to depend on the taste of
the individual developer.

I think that for this particular case, vecir.h, the #error is there to
make sure that coretypes.h is explicitly included.

Ciao!
Steven


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