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
