[Bug c/27349] New: Fortran function returns are not correct in c on X86_64
-- Summary: Fortran function returns are not correct in c on X86_64 Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ray at ultramarine dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27349
[Bug c/27350] New: Fortran function returns are not correct in c on X86_64
gcc3.4.4 on x86_64 When a c program calls a fortran function which returns a "real" value the c program gets the wrong answer. -- Summary: Fortran function returns are not correct in c on X86_64 Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ray at ultramarine dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27350
[Bug c/27350] Fortran function returns are not correct in c on X86_64
--- Comment #1 from ray at ultramarine dot com 2006-04-28 14:25 --- Created an attachment (id=11343) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11343&action=view) All necessary files to produce the bug go is a csh script that compiles the fortran, compiles the c, links and runs. The first output is from the fortran which is correct, 500. The second print is from the c and is 0. This works correctly with the 32 bit compilers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27350
[Bug fortran/27757] New: Problems with direct access io
I have a relatively stable, relatively large fortran program (500,000+ lines). This program works correctly on linux, 64 bit linux, solaris, and windows when compiled with g77 3.4.4. When I complile it with gfortran 4.1.0, 26 out of 384 of my regerssion tests fail because of i/o errors. Basically, I have databases which are accesses via direct access, unformatted io. All transactions pass through two routines: a writter and a reader. I have attached a tar file which contains the two routines. Basically, they write two words at the beginning of each record - the current numbers of "saus" (sort integers) and the record which continues this record. Also attached is a file, trans, which shows the reads and writes. Each line in the file contains the action (dba_read or dba_write), the fortran unit number, the record number, the number of short integers on this record, the continuation record, and finally the record length. (The print statements that created this file are commentd out in the source). If you notice the last line in this file says that record 2958 on logical unit 15 has 1 short integer, but 4 lines up, it has 122 and is continued on 2959. Notice that there have been writes to this file, but at different record numbers. I would really like to give you a better report, but the fact that 350 tests work properly says that any attempt to create a simple test will probably fail (the code will work properly). I will be happy to do anything you would like to help in the resolution of this problem. In particular, it you would like for me to test any changes, please just send me the library and I can get back to you within a couple of hours. -- Summary: Problems with direct access io Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ray at ultramarine dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27757
[Bug fortran/27757] Problems with direct access io
--- Comment #1 from ray at ultramarine dot com 2006-05-24 14:58 --- Created an attachment (id=11505) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11505&action=view) source and results -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27757
[Bug fortran/27757] Problems with direct access io
--- Comment #3 from ray at ultramarine dot com 2006-05-25 01:03 --- Subject: Re: Problems with direct access io On Wed, 25 May 2006, jvdelisle at gcc dot gnu dot org wrote: > > > --- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-05-25 00:51 > --- > I will take a look at this one. This does seem odd. Can you tell us what > platform you are running on and what version of gfortran. > > gfortran -v will tell us useful info. > > Actually I included this information 4.1.0. The results submitted were run on an AMD x86_64 machine, but the exactly same thing occurs on an Intel dual core P4 with Fedora Core 4 (a 32 bit OS). Thank you and if I can do anything to help, please let me know. Thanks, Ray -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27757
[Bug fortran/27757] Problems with direct access io
--- Comment #5 from ray at ultramarine dot com 2006-05-25 02:17 --- Subject: Re: Problems with direct access io On Wed, 25 May 2006, jvdelisle at gcc dot gnu dot org wrote: > > > --- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-05-25 01:20 > --- > If you are running a gfortran straight from the FC 4 distribution it probably > does not have the latest fixes to the IO that we have in the 4.1 branch. > These > have not been released yet. Release 4.1.1 is being prepared now. > > If you are up to it you could grab a gcc snapshot and build a 4.1.1 or 4.2 > version and try it. 4.2 may not be very stable at the moment so a 4.1 > snapshot > latest would be a good bet. > > Let me know what you think and we will keep trying to help you with this. > I am really a big boy. Tried to get the latest snapshot but could not find it! Send url, I will make it, test it, and report tomorrow. Thanks again, Ray -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27757
[Bug fortran/27757] Problems with direct access io
--- Comment #9 from ray at ultramarine dot com 2006-05-27 12:21 --- Subject: Re: Problems with direct access io Good work, knew this would be hard! Ray On Sat, 27 May 2006, jvdelisle at gcc dot gnu dot org wrote: > > > --- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-05-27 05:10 > --- > Here is some good news. I came up with a test case that fails with gfortran > and passes with intel. The bad news is that I have not fixed it yet. At > least > I have something to work with now and its ugly. > > program testdirect > implicit none > integer, dimension(100) :: a > integer :: i,j,k,ier > real:: x > > a = 0 > call random_seed() > open(unit=15,file="testdirectio",access="direct",form="unformatted",recl=4) > do i=1,100 > call random_number(x) > k= int(x * 100)+1 > a(i)=k > write(unit=15, rec=k) k > enddo > do j=1,100 > read(unit=15, rec=a(j), iostat=ier) k > if (ier.ne.0) then > print *, "No Record: ", j > else > print *, "Bad Record at ",a(j), k > endif > enddo > close(unit=15, status="delete") > end program testdirect > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27757 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > > ---+ Spam Scoring Results + > Content analysis details: (0.0 hits, 5.0 required) > 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% > [score: 0.5002] > > ---+ End Spam Scoring Results +--- > Ultramarine, Inc. http://www.ultramarine.com Phone: 713-975-8146 Fax: 713-975-8179 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27757
[Bug fortran/27757] Problems with direct access io
--- Comment #11 from ray at ultramarine dot com 2006-05-27 20:53 --- Subject: Re: Problems with direct access io I believe I said that in the bug report. On Sat, 27 May 2006, tkoenig at gcc dot gnu dot org wrote: > > > --- Comment #10 from tkoenig at gcc dot gnu dot org 2006-05-27 19:10 > --- > This bug does not occur with g77, as this version of the > test program shows: > > $ cat testdirect.f > program testdirect > implicit none > integer a (100) > integer i,j,k,ier > real x > integer myrand(100) > > data myrand / 13, 9, 34, 41, 25, 98, 6, 12, 11, 44, 79, 3, > &64, 61, 77, 57, 59, 2, 92, 38, 71, 64, 31, 60, 28, 90, 26, > &97, 47, 26, 48, 96, 95, 82, 100, 90, 45, 71, 71, 67, 72, > &76, 94, 49, 85, 45, 100, 22, 96, 48, 13, 23, 40, 14, 76, 99, > &96, 90, 65, 2, 8, 60, 96, 19, 45, 1, 100, 48, 91, 20, 92, > &72, 81, 59, 24, 37, 43, 21, 54, 68, 31, 19, 79, 63, 41, > &42, 12, 10, 62, 43, 9, 30, 9, 54, 35, 4, 5, 55, 3, 94 / > > do i=1,100 > a(i) = 0 > end do > C call random_seed() > open(unit=15,file="testdirectio",access="direct", > & form="unformatted",recl=4) > do i=1,100 > k = myrand(i) > ! k= int(x * 100)+1 > a(i)=k > write(unit=15, rec=k) k > end do > > do j=1,100 > read(unit=15, rec=a(j), iostat=ier) k > if (ier.ne.0) then > print *, "No Record: ", j > else > if (a(j) .ne. k) print *, "Bad Record at ",a(j), k > endif > enddo > close(unit=15, status="delete") > end > $ g77 testdirect.f > $ ./a.out > $ gfortran testdirect.f > $ ./a.out > Bad Record at 13 14 > Bad Record at 34 0 > Bad Record at 25 26 > Bad Record at 98 99 > Bad Record at6 11 > Bad Record at 11 0 > Bad Record at 44 45 > Bad Record at 64 65 > Bad Record at 61 0 > Bad Record at 77 0 > Bad Record at 57 59 > Bad Record at2 0 > Bad Record at 38 0 > Bad Record at 71 72 > Bad Record at 64 65 > Bad Record at 60 0 > Bad Record at 28 0 > Bad Record at 90 98 > Bad Record at 26 34 > Bad Record at 97 0 > Bad Record at 47 48 > Bad Record at 26 34 > Bad Record at 96 97 > Bad Record at 95 96 > Bad Record at 82 0 > Bad Record at 90 98 > Bad Record at 45 0 > Bad Record at 71 72 > Bad Record at 71 72 > Bad Record at 67 0 > Bad Record at 76 0 > Bad Record at 49 0 > Bad Record at 85 0 > Bad Record at 45 0 > Bad Record at 22 23 > Bad Record at 96 97 > Bad Record at 13 14 > Bad Record at 23 0 > Bad Record at 40 0 > Bad Record at 14 0 > Bad Record at 76 0 > Bad Record at 99 100 > Bad Record at 96 97 > Bad Record at 90 98 > Bad Record at 65 0 > Bad Record at2 0 > Bad Record at8 0 > Bad Record at 60 0 > Bad Record at 96 97 > Bad Record at 45 0 > $ g77 -v > Reading specs from /usr/lib/gcc/i486-linux-gnu/3.4.6/specs > Configured with: ../src/configure -v --enable-languages=c,c++,f77,pascal > --prefix=/usr --libexecdir=/usr/lib > --with-gxx-include-dir=/usr/include/c++/3.4 > --enable-shared --with-system-zlib --enable-nls --without-included-gettext > --program-suffix=-3.4 --enable-__cxa_atexit --enable-clocale=gnu > --enable-libstdcxx-debug --with-tune=i686 i486-linux-gnu > Thread model: posix > gcc version 3.4.6 (Debian 3.4.6-1) > $ gfortran -v > Using built-in specs. > Target: i686-pc-linux-gnu > Configured with: ../../gcc/trunk/configure --prefix=/home/ig25 > --enable-languages=c,fortran > Thread model: posix > gcc versio
[Bug fortran/27757] [4.1/4.2 Regression] Problems with direct access io
--- Comment #13 from ray at ultramarine dot com 2006-05-28 19:06 --- Subject: Re: [4.1/4.2 Regression] Problems with direct access io On Sat, 28 May 2006, jvdelisle at gcc dot gnu dot org wrote: > > > --- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-05-28 00:40 > --- > I am confirming this is a regression. The test program works fine on 4.0.2 > Thanks, I thought it had worked before but could not find out when! Ray -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27757
[Bug bootstrap/28124] New: Cannot build gcc on OSX 10.4 G6
Making cgg on Mac Mini G5 with OSX 10.4 aborts with checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details. make[1]: *** [configure-target-libstdc++-v3] Error 1 make: *** [all] Error 2 -- Summary: Cannot build gcc on OSX 10.4 G6 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ray at ultramarine dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28124
[Bug bootstrap/28124] Cannot build gcc on OSX 10.4 G6
--- Comment #2 from ray at ultramarine dot com 2006-06-21 15:00 --- Subject: Re: Cannot build gcc on OSX 10.4 G6 On Wed, 21 Jun 2006, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-21 14:58 > --- > What do you mean by G6 there is no such thing. > Sorry about that G5 was intended, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28124
[Bug libfortran/24918] New: GFORTRAN input and carriage returns
-- Summary: GFORTRAN input and carriage returns Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ray at ultramarine dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24918
[Bug libfortran/24919] New: GFORTRAN input and carriage returns
When reading a "dos" file, gfortran returns two records for each line
in the file: the real record and a null one. In other words it is treating
the carriage return as a newline instead of the pair carriage return/newline
as the newline.
Here is an example:
integer ios
character buf*(50)
c
open(10,file='dos',iostat=ios)
print *,' open ios ',ios
1000 read(10,'(a)',iostat=ios) buf
if(ios .ne.0) go to 9000
print '(a,a,a)',' read <',buf,'>'
go to 1000
c
9000 end
--
Summary: GFORTRAN input and carriage returns
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ray at ultramarine dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
[Bug fortran/24921] New: iostat on read
-- Summary: iostat on read Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ray at ultramarine dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24921
[Bug fortran/24923] New: iostat on read
The following has a problem integer buf(200),ios buf(1) = -77 buf(2) = -77 open(10,file='cow',access='DIRECT',recl=100,iostat=ios) print *,' open ios ',ios read(10,rec=1,iostat=ios) buf print *,' read ios ',ios print *,' buf 1 2 ',buf(1),buf(2) end When executed it creates an empty file. When the first record is read, it returns iostat=0 and changes the first two integers. Iostat should not be zero because the read was not finished. -- Summary: iostat on read Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ray at ultramarine dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24923
[Bug libfortran/24919] GFORTRAN input and carriage returns
--- Comment #3 from ray at ultramarine dot com 2005-11-17 20:28 --- Subject: Re: GFORTRAN input and carriage returns On Thu, 17 Nov 2005, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-17 20:13 > --- > First can you try 4.0.2 or a snapshot of 4.0.3? Second can you attach the dos > file? > > > -- > > pinskia at gcc dot gnu dot org changed: > >What|Removed |Added > > CC||pinskia at gcc dot gnu dot >||org > > Sorry, but there was no good way to do that with the form. --- Comment #4 from ray at ultramarine dot com 2005-11-17 20:28 --- Created an attachment (id=10268) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10268&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
[Bug fortran/24923] iostat on read
--- Comment #3 from ray at ultramarine dot com 2005-11-18 19:30 --- (In reply to comment #2) > Actually this has already been fixed for 4.0.3 at least: > open ios0 > read ios3 > buf 1 2 -77 -77 > Due to other bugs, I took your advice and downloaded a 4.1 snapshot yesterday. With this, the program aborts with: a.out: relocation error: a.out: undefined symbol: _gfortran_transfer_array -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24923
[Bug libfortran/24919] GFORTRAN input and carriage returns
--- Comment #8 from ray at ultramarine dot com 2005-11-18 19:32 --- (In reply to comment #3) > Subject: Re: GFORTRAN input and carriage returns > > On Thu, 17 Nov 2005, pinskia at gcc dot gnu dot org wrote: > > > > > > > --- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-17 20:13 > > --- > > First can you try 4.0.2 or a snapshot of 4.0.3? Second can you attach the > > dos > > file? Tried yesterday's snapshot of 4.1 and it still does not work. > > > > > > -- > > > > pinskia at gcc dot gnu dot org changed: > > > >What|Removed |Added > > > > CC||pinskia at gcc dot gnu dot > >||org > > > > > > Sorry, but there was no good way to do that with the form. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
[Bug fortran/24923] iostat on read
--- Comment #5 from ray at ultramarine dot com 2005-11-18 20:51 --- Subject: Re: iostat on read On Fri, 18 Nov 2005, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-18 20:03 > --- > (In reply to comment #3) > > a.out: relocation error: a.out: undefined symbol: > > _gfortran_transfer_array > > That means your LD_LIBRARY_PATH is finding an old version of libgfortran. > Thanks so much (thought it was statically linked). It works now, Ray -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24923
[Bug libfortran/24919] GFORTRAN input and carriage returns
--- Comment #10 from ray at ultramarine dot com 2005-11-21 13:52 ---
(In reply to comment #9)
> (In reply to comment #8)
> > Tried yesterday's snapshot of 4.1 and it still does not work.
>
> OK, I'm on it. Looks like someone forgot about CRLF systems :)
>
> I'll try to submit a first patch tomorrow...
>
The following changes in transfer.c appear to fix the problem in Linux:
157c157
< char *base, *p, *q;
---
> char *base, *p, *q, last;
173a174
> last= 0;
197c198
< if (readlen < 1 || *q == '\n' || *q == '\r')
---
> if (readlen < 1 || *q == '\n' )
215a217,219
> if ( last == '\r') {
> *length = n-1;
> } else {
216a221
> }
222a228
> last = *q;
Ray
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24919
[Bug fortran/30713] New: Internal Complier Error
Attached code generates on Internal Complier Error when using -O3 on an Intel Mac -- Summary: Internal Complier Error Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ray at ultramarine dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30713
[Bug fortran/30713] Internal Complier Error
--- Comment #2 from ray at ultramarine dot com 2007-02-06 15:39 --- Subject: Re: Internal Complier Error On Tue, 6 Feb 2007, kargl at gcc dot gnu dot org wrote: > > > --- Comment #1 from kargl at gcc dot gnu dot org 2007-02-06 15:36 --- > There is no attached code. Ray can you try adding the code, again. > Really sorry about that but got an internal bugzilla error when I tried. --- Comment #3 from ray at ultramarine dot com 2007-02-06 15:39 --- Created an attachment (id=13014) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13014&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30713
[Bug fortran/30713] Internal Complier Error
--- Comment #5 from ray at ultramarine dot com 2007-02-06 17:00 --- Subject: Re: Internal Complier Error On Tue, 6 Feb 2007, burnus at gcc dot gnu dot org wrote: > > > --- Comment #4 from burnus at gcc dot gnu dot org 2007-02-06 16:34 > --- > Not that it much helps, but with today's gcc under x86_64-unknown-linux-gnu it > does not crash. > Maybe someone with Intel Mac can reproduce it. > > Oherwise: > Compile with the "-v" option, e.g. gfortran -v -O3 env_grid.f > After the line "gcc-Version 4.3.0 20070206 (experimental)" is the actual > compilation command. On my computer it looks like: > /projects/tob/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 > env_grid.f -ffixed-form ... > > Run now (replace the argument with yours of above) > gdb /projects/tob/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 > (gdb) b real_abort > (gdb) b fancy_abort > (gdb) run env_grid.f -ffixed-form (... and the rest of the options) > > When it stops, enter > (gdb) bt > > This gives a backtrace and a hint where the error occurs. What exact version > of > gfortran did you try? Do you know by chance whether this is a new problem or > was present in a previous version of gfortran 4.3? If you will look in the "log" file it contains the results of both uname -a and gfortran -v. It says gcc version 4.3.0 20070104 (experimental) I tried the above, but did not get any trace. Message said no stack. I have no idea if this is an old or a new problem. I am mostly using 4.1 on solaris, linux, and mac (power pc). This is the first time I have seen the problem. If it helps, I got around the problem by making the code from line 105 to 117 into a subroutine. Also, the problem does not exist without -O3. Sorry I could not be of more help, Ray -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30713
[Bug fortran/30981] New: Program "Hangs"
If a has a value of +Infinity, then a program will "hang" (run forever) when
b = x**a
is executed.
The traceback shows that this occurs in the library routine pow_r4_i4
uname -a
Linux devlop 2.6.16.13-4-smp #1 SMP Wed May 3 04:53:23 UTC 2006 x86_64 x86_64
x86_64 GNU/Linux
gfortran -v
===
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /e_source/gcc-4.1.1/configure --prefix=/add/linux64/gcc4.1.1
Thread model: posix
gcc version 4.1.1
--
Summary: Program "Hangs"
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ray at ultramarine dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
[Bug fortran/30981] Program "Hangs"
--- Comment #2 from ray at ultramarine dot com 2007-02-27 18:00 --- Subject: Re: Program "Hangs" On Tue, 27 Feb 2007, burnus at gcc dot gnu dot org wrote: > > > --- Comment #1 from burnus at gcc dot gnu dot org 2007-02-27 17:07 > --- > Could you post an example? > > pow_r4_i4 means that you have x**a = ** > > I don't see how the exponent "a" can be infinity if it is an integer(4). > subroutine num_normalize(sigfig,number, n_normal,exponent) c c@@@ c@@@ c@@@ c c --- num_normalize --- c c Copyright Ultramarine,inc. c August 1997 c c.D c.D NAME=num_normalize c.D Routine to crack NUMBER to characters in ARRAY c.D OUTPUT c.D ARRAY = Character array of NUMBER c.D NPLACE = Integer*4 Number of Characters used c.Dif NPLACE < 0 then could not convert c.D c c@@@ c@@@ c@@@ c c c c* no implicit c implicit none c c* externals c c c* global variables c include '$(where)/amos/include/essential.ecm' c c* local variables c TYPE_INTEGER exponent,sigfig,pow TYPE_REAL number,temp,n_normal,eps parameter (eps = 1e-6) c c* initialize c temp = abs(number) if( temp .lt. r_tiny_n) then exponent = 0. n_normal = 0. else exponent = log10(temp) c hangs after here. temp = temp / (10.**exponent) pow = max(sigfig,(exponent+1)) n_normal = temp + 5./10.**pow endif c c* fix? c if ( n_normal .ge. 10.-eps .and. n_normal .le. 10+eps ) then exponent = 0 n_normal = 10 - eps elseif( n_normal .ge. 10. ) then exponent = exponent + 1 temp = temp * .1 pow = max(sigfig,(exponent+1)) n_normal = temp + 5./10.**pow elseif( n_normal.lt. 1.) then exponent = exponent - 1 temp = temp * 10. pow = max(sigfig,(exponent+1)) n_normal = temp + 5./10.**pow endif c c* all done c return c end > And the following program executes in <4 ms with gfortran 4.3.0 20070227 and > 4.1.3 20070218 (prerelease) (SUSE Linux). > > You might want to try an newer GCC (4.1.2 or 4.2 or 4.3). > Nightly builds of the latter two are available from: > http://gcc.gnu.org/wiki/GFortranBinaries#GNU/Linux Thanks, I know about the newer versions, but what I have here is basically working. I just reported this because I hate hangs even when I have a bug and generate infinity and then try to convert it to a string. Thanks again, Ray PS. Notice the "eps" in the last segment of code. This is really a bug also. It originally was If ( n_normal .eq. 10. ) then But in some cases it missed the proper branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
[Bug fortran/30981] a ** exp fails for integer exponents if exp is "-huge()-1" (endless loop)
--- Comment #4 from ray at ultramarine dot com 2007-02-27 19:52 ---
Subject: Re: a ** exp fails for integer exponents if exp
is "-huge()-1" (endless loop)
On Tue, 27 Feb 2007, burnus at gcc dot gnu dot org wrote:
>
>
> --- Comment #3 from burnus at gcc dot gnu dot org 2007-02-27 19:35
> ---
> Hi,
>
> > > Could you post an example?
>
> With example I mean something which actually compiles and runs. Here, I have
> two problems:
> include '$(where)/amos/include/essential.ecm'
> is missing as well as the main program which calls the routine. And as always:
> The smaller the better.
I really try to do this, but I am an "old" fortran programer and
I do not know how to set +Infinity. Yes, of course, I have a case
that computes it and then hangs, but my code is over 500,000 lines
long and I did not think it is appropriate.
> In addition, please attach such long files, they clutter the bug report page
> quite a bit if they are put into the comment field.
>
> > if ( n_normal .ge. 10.-eps .and. n_normal .le. 10+eps ) then
> >
> > PS. Notice the "eps" in the last segment of code. This is
> > really a bug also. It originally was
> > If ( n_normal .eq. 10. ) then
> > But in some cases it missed the proper branch.
>
> If you do:
> n_normal = 10.0
> then if(n_normal == 10.0) should work. If you do
> n_normal = 500.0/100.0*2.0
> then it might not work due to rounding errors and representation problems of a
> decimal number as binary number. Therefore, one should almost always use
> something like if ( abs(n_normal - 10.0) < eps), where eps is sensibly
> chosen, it could be e.g. eps = epsilon(n_normal), but this might be even too
> small. For irrational numbers such as 3.14159 it is more obvious that one
> should use, e.g. (abs(myNumber - 3.14159) < 1e-4) instead of "if (myNumber ==
> 3.14159)".
This is not as silly as it sounds. All I care about is to handle
the special case of 10 (exactly). I have seen cases where the
equality fails, but the number is really 10. It probably has
something to do with how this is done. I never could get a
small case to fail.
> Back to the problem:
>
> The calculation goes only into an endless loop if the exponent is
> "-huge(integer)-1".
>
> Test case:
> program test
> implicit none
> print *, 5.0**(-huge(i)-1)
> end program
>
> The problem is that in pow_r4_i4 the following operation is done:
>
> if (n < 0)
> {
> n = -n;
>
> The problem is: For n == -huge(n) - 1 exists no positive number. Thus
> n == -n == -2147483648 (for integer(4))
>
>
> --
>
> burnus at gcc dot gnu dot org changed:
>
>What|Removed |Added
>
> Status|UNCONFIRMED |NEW
> Ever Confirmed|0 |1
>Keywords||wrong-code
>Last reconfirmed|-00-00 00:00:00 |2007-02-27 19:35:04
>date||
> Summary|Program "Hangs" |a ** exp fails for integer
>||exponents if exp is "-
>||huge()-1" (endless loop)
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>
> ---+ Spam Scoring Results +
> Content analysis details: (-2.6 hits, 5.0 required)
> -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
> [score: 0.0033]
>
> ---+ End Spam Scoring Results +---
>
Ultramarine, Inc.
http://www.ultramarine.com
Phone: 713-975-8146
Fax: 713-975-8179
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
[Bug fortran/30981] a ** exp fails for integer exponents if exp is "-huge()-1" (endless loop)
--- Comment #6 from ray at ultramarine dot com 2007-02-27 19:57 --- Subject: Re: a ** exp fails for integer exponents if exp is "-huge()-1" (endless loop) On Tue, 27 Feb 2007, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #5 from pinskia at gcc dot gnu dot org 2007-02-27 19:54 > --- > Also isn't -huge()-1 undefined code for Fortran? > > > -- I am not familiar with the new standards, but it was in the past. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
