Re: [Patch, fortran, 4.9] Use bool type instead gfc_try

[Tobias Burnus <burnus at net-b dot de>]

N.M. Maclaren wrote:
> On Mar 22 2013, Miles Bader wrote:
> > > That is another matter entirely.  The code of gcc/gfortran is supposed
> > > to be compilable with other compilers, and it is foolish to make
> > > unnecessary assumptions by relying on undefined behaviour.
> > >
> > > The simple facts are that C++ does NOT define bool to be compatible 
> > > with
> > > _Bool, and there are enough differences in specification and semantics
> > > to make it likely that they are not the same in at least some 
> > > compilers.
> > > This mess has caused and still causes no end of problems for Fortran
> > > interoperability and in standards like MPI.
> >
> > Er, maybe so, but is there actually an issue in _this_ case?
>
> Yes.  There are many ways of resolving it, one of which is to state that
> gfortran MUST be compiled in a second pass using gcc, after having built
> gcc.  Another is described below.

Well, the recommend way to compile GCC is to bootstrap it. That uses the 
system compiler (or whatever the user has) to compile GCC's C and C++ 
compilers; those are then used to compile GCC (this time including the 
Fortran front end) - for the compiler: twice, once without (stage 2) and 
once with (stage 3) debugging symbols. Then, the generated code is 
compared and shall not differ.

Users can compile GCC also without bootstrapping. However, I also do not 
see problems: Older GCC are compiled by C, newer by C++. But C and C++ 
are not mixed and this "bool" is really only used internally in the 
compiler and internally in the libgfortran run-time library (the latter 
is always compiled by GCC 's just created C compiler).

Thus, I do not see how this can cause problems.

That's different to user code, where mixing Fortran's LOGICAL, C's and 
C++'s bool can cause problems - as can passing an C or C++'s "int" to a 
Fortran LOGICAL (or without prototype: To C/C++'s bool). Or using 
different Fortran compilers with LOGICAL. I concur that this is an 
underestimated problem, but I fail to see how it applys here.


> And that is precisely the point.  The risk isn't in either of them,
> but in any interface that passes C++ bool from the front-end to C99
> _Bool in the back end.  If you exclude that, there is no problem.

The front end and the backend are both compiled with the same compiler 
and in the same binary. Even without bootstrapping, trying to compile 
them with different compilers, will require some heavy editing of 
makefiles. Thus, it seems to be extremely unlikely that different 
compilers have ever been used.  The change from C99's bool to C++'s bool 
occurred for the whole compiler. Before 4.7 the default was to compile 
GCC with C (though it had been modified to be also compilable with C++); 
in 4.7, the default compiler was C++ but C was still supported. And 
since GCC 4.8 C++ features are used, which makes GCC only compilable 
with C++. Actually, the FE itself so far uses nearly no C++ features, it 
is the middle end which used them (which 'leak' to the front end via 
some helper macros/functions).


> My point here is that it is VERY important not to read the political
> sound-bite that C++ is now based on C99 and assume that they are
> actually compatible in all respects where they have 'equivalent'
> facilities.  They aren't.

In terms of the discussion, "bool" is used for quite some time in 
gfortran (the frontend) and libgfortran. When GCC was compiled with C, 
that was C99's _Bool. Since the compiler is compiled as C++, it is C++'s 
"bool". Thus, C/C++'s bool are never mixed.

Tobias