This is the mail archive of the gcc-bugs@gcc.gnu.org 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]

[Bug fortran/33252] GCC-4.3.0 Bootstrap testsuite error increase



------- Comment #13 from fxcoudert at gcc dot gnu dot org  2007-08-31 11:10 -------
Allow me to step in... michelin60, what about discussing constructively? Here
are the comments I can make one the failures and your remarks. Please answer to
them, or ask further questions if something isn't clear.

> FAIL: gfortran.dg/fmt_p_1.f90  -O0  execution test
> FAIL: gfortran.dg/large_real_kind_form_io_1.f90  -O0  execution test
> FAIL: gfortran.dg/output_exponents_1.f90  -O0  execution test

As explained earlier, these failures are due to a patch that was reverted in
less than 48 hours. This is a good example of why large testing of development
branches is important, as well as a good example of why you shouldn't use a
development branch for production.

> FAIL: gfortran.dg/large_real_kind_form_io_2.f90  -O0  execution test

This one has been failing for quite some time. It concerns the output of very
large real(kind=16) numbers, which are output as infinities. What is missing
for Jerry or I to develop a patch is access to such a machine (ppc-darwin,
ppc-linux or a recent sparc-solaris are good candidates). This is considered a
corner case, and thus of lower importance.

> FAIL: gfortran.dg/nint_2.f90  -O0  execution test

This one is annoying, I think I had it fixed (I saw it on numerous targets, and
fixed it on most... I believed it was fixed on all targets). If you are willing
to get this fixed, please open a PR specifically for this problem, adding the
relevant output from ${builddir}/gcc/testsuite/gfortran/gfortran.log.
Additionally, you might want to compile and run the testcase outside of the
testsuite framework, see what happens and put that into the bugreport.
Hopefully, I can work on fixing that with you (asking you to perform any
further inquiries).

> Please bring this to the attention of the appropriate gfortran people. As a
> chemical engineer I am distressed that the gfortran people are not allowed any
> more to backport strictly fortran frontend improvements. Both gcc-4.2.x and
> gcc-4.3.0 in the eyes of many observers and even GCC maintainers leave a lot
> to be desired.

"backporting" means "porting changes, originaly designed for the development
branch [here 4.3], to release branches [branches for which at least one version
was released, like 4.2 and 4.1]". The exact rule in place for GCC development
is that only patches fixing regressions can be backported to release branches
(a regression is a bug that wasn't present in older versions but appeared at
some point). This prevents (among other things) new features to be introduced
in old branches. This is done to keep release branch stables, to avoid
introducing regressions inside a branch. The golden rule here is: all user code
that compiled fine with version 4.2.x should compile fine with later versions
4.2.y (y > x). A user should never face negative consequences for upgrading his
compiler inside a given branch.

Now, the backport limitation cannot hurt 4.3, because it is the development
branch. We can (and do) perform any change that we deem necessary to the
development branch, either to introduce new features, to fix bugs (be them
regressions or not).

Now, any judgment on the intrinsic quality of a compiler is very difficult to
make. If there are specific problems you encounter with gfortran, I see
basically 3 ways you can get it improving:
  * reporting your specific problems (one PR per bug/misbehaviour encountered)
  * contributing time to the project (reporting bugs is one of them, regularly
testing GCC on differents platforms you have access to is another, as is
helping Fortran newbies on the mailing-list; this gives more time to the
maintainers to actually maintain the compiler itself)
  * contributing resources to the project (e.g. access to specific hardware)

Short of that, well, you still have the option of using/buying another
compiler.

PS: most developers of gfortran are also end-users of the compiler, and
volunteers. Most of us are academic or private researchers. Writing this long
explanation took 30 minutes of my working day, and thus impacted my own
resarch, so please consider it seriously. (I also am a working in physical
chemistry, have a few friends working with Michelin.)


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
  GCC build triplet|powerpc                     |powerpc-unknown-linux-gnu
   GCC host triplet|powerpc                     |powerpc-unknown-linux-gnu
 GCC target triplet|powerpc                     |powerpc-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33252


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