Re: [Bug fortran/20178] COMPLEX function returns incompatible with g77
tobi at gcc dot gnu dot org wrote: --- Additional Comments From tobi at gcc dot gnu dot org 2005-05-10 22:23 --- Fixed on the mainline. I will commit this to the branch after the obligatory testing and the necessary changes (unfortunately -fsecond-underscore became the default on the branch). [ Sorry for the late reply ] I wonder if that really means we have to stick to -fsecond-underscore on the 4.0 branch. Only 4.0.0 is out, and it is very probable that *nobody* uses it for any serious work in Fortran anyway. I feel we can safely change the default, even on the branch. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Re: [Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
corsepiu at gcc dot gnu dot org wrote: Joel, do you recall the target in RTEMS which has 4-byte floats only? (We recently had an issue with it floating point context sizes related to it? IIRC, it had been a powerpc variant and we were forced to drop it because GCC doesn't support it. BTW1: IFAIK, there also exist sh-variants (target tuple *-single*) which don't have 8byte floats. RTEMS doesn't support them, so I've never tried to build fortran for then. Note that the major demand the Fortran Standard places on DOUBLE PRECISION is that it takes up twice the amount of storage. It also is supposed to be of "higher precision", but that is a QOI issue. Cheers, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ News on GNU Fortran 95: http://gfortran.org/
Re: Severe problems running the g77 test suite on the main line
Peter Schmid wrote: > After applying the following patch the g77 testsuite runs again. I > confirmed that it links versus the libg2c included in the build > tree. > I know next to nothing of dejagnu, therefore this patch may be > inelegant, or even incorrect. > I generated this patch by gleaning the necessary bits from > objc.exp. Wow - thanks a lot ! I looked into the g++.exp file, but didn't get any wiser from it. Unless someone comes up with something better, I'll apply this tonight. -- Toon Moene, KNMI, PO Box 201, 3730 AE De Bilt, The Netherlands. Tel. +31302206443, Fax +31302210407, e-mail [EMAIL PROTECTED] URL: http://www.knmi.nl/hirlam
Re: [Bug middle-end/18902] Naive (default) complex division algorithm
pcarlini at suse dot de wrote:
--- Additional Comments From pcarlini at suse dot de 2005-01-20 12:10
---
A first implementation of the algorithm was already in 3_4, under the name
expand_cmplxdiv_wide (in optabs.cc), then Rth rewrote it in the tree-ssa branch
as part of the new tree-complex.cc (It would be mildly interesting to see if
the version in 3_4 works) In the meanwhile, I'm adding Rth in CC of 19486.
Indeed (ChangeLog.1):
Tue May 18 03:53:37 1999 Craig Burley <[EMAIL PROTECTED]>
Improve open-coding of complex divide:
* flags.h: Declare new front-end-malleable flag.
* toplev.c: Define new flag.
* optabs.c (expand_cmplxdiv_straight): New function to do original
open-coding.
(expand_cmplxdiv_wide): New function to do new open-coding,
from Toon Moene, with changes (call to emit_barrier, dropping
of spurious `ok = 1;', plus the obvious `break;' -> `return 0;').
(expand_binop): A bit of spacing fixing, while at it.
Use new functions instead of inlining the open-coding code.
--
Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
