--- Comment #12 from kargl at gcc dot gnu dot org 2005-12-02 00:57 ---
Fixed.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from kargl at gcc dot gnu dot org 2005-12-02 01:27 ---
Patch applied.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #19 from kargl at gcc dot gnu dot org 2005-12-09 18:16 ---
I've tested this patch on amd64-*-freebsd. It cures my
gfortran failures. Who do we need to ping to get this
approved?
--
kargl at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from kargl at gcc dot gnu dot org 2005-12-10 04:58 ---
The patch from comment #6 no longer applies. It appears that this ChangeLog
2005-12-07 Jorn Rennecke [EMAIL PROTECTED]
* reload.h (reg_equiv_invariant): Declare.
* reload.c
--- Comment #1 from kargl at gcc dot gnu dot org 2005-12-10 16:55 ---
What is the bug?
9.4.1.6 End-of-file branch
If an end-of-file condition (9.4.3) occurs and no error condition (9.4.3)
occurs during execution of an input statement that contains an END= specifier
(1
--- Comment #7 from kargl at gcc dot gnu dot org 2005-12-11 00:39 ---
Subject: Bug 25068
Author: kargl
Date: Sun Dec 11 00:39:14 2005
New Revision: 108371
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108371
Log:
Fix testsuite after this commit:
2005-12-10 Francois-Xavier
--- Comment #5 from kargl at gcc dot gnu dot org 2005-12-11 16:47 ---
http://gcc.gnu.org/ml/fortran/2005-12/msg00215.html
This patch changes the handling of labels to catch
problems with too many digits from laeding zeros.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25106
--- Comment #2 from kargl at gcc dot gnu dot org 2005-12-11 16:47 ---
Patch http://gcc.gnu.org/ml/fortran/2005-12/msg00215.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25055
--- Comment #2 from kargl at gcc dot gnu dot org 2005-12-11 17:06 ---
I have a tentative patch for this bug.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2005-12-11 18:45 ---
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00826.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25078
--- Comment #2 from kargl at gcc dot gnu dot org 2005-12-12 20:06 ---
I don't see this problem on FreeBSD with either static of dynamic
linking. Note, in both cases, I am picking up csqrt() from libgfortran.
What platform are you using? Is this another glibc problem? Does
-fdump-tree
--- Comment #4 from kargl at gcc dot gnu dot org 2005-12-12 20:13 ---
Subject: Bug 25078
Author: kargl
Date: Mon Dec 12 20:13:37 2005
New Revision: 108426
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108426
Log:
PR fortran/25078
* match.c (gfc_match_equivalence
--- Comment #3 from kargl at gcc dot gnu dot org 2005-12-14 17:29 ---
Technically, gfortran can do whatever it wants, because
the code is nonconforming. The tab character is not a
member of the Fortran character set. The code is using
a tab where a member of the Fortran character set
--- Comment #5 from kargl at gcc dot gnu dot org 2005-12-14 18:55 ---
Subject: Bug 25078
Author: kargl
Date: Wed Dec 14 18:55:31 2005
New Revision: 108531
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108531
Log:
2005-12-12 Steven G. Kargl [EMAIL PROTECTED]
PR fortran
--- Comment #6 from kargl at gcc dot gnu dot org 2005-12-14 18:57 ---
Fixed.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from kargl at gcc dot gnu dot org 2005-12-14 19:11 ---
Changed severity to normal.
This doesn't compile because wave.inc is
not available and prec.mod is not present.
MODULE WAVE
USE prec
USE mpimy
INCLUDE wave.inc
--
kargl at gcc dot gnu
--- Comment #2 from kargl at gcc dot gnu dot org 2005-12-15 17:41 ---
Gfortran will never support a real*16 data type on IA32 hardware.
This would require software emulation of all of basic floating-point
arthimetic as well as implementation/modification of all intrinsic
procedures
--- Comment #4 from kargl at gcc dot gnu dot org 2005-12-15 20:34 ---
(In reply to comment #3)
I was not suggesting to introduce a new datatype for real*16, but that
the same type that is used for long double in C is available as real*16
in Fortran, if the option -m128bit-long-double
--- Comment #3 from kargl at gcc dot gnu dot org 2005-12-16 23:32 ---
Subject: Bug 25055
Author: kargl
Date: Fri Dec 16 23:32:29 2005
New Revision: 108692
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108692
Log:
2005-12-10 Steven G. Kargl [EMAIL PROTECTED]
PR fortran
--- Comment #6 from kargl at gcc dot gnu dot org 2005-12-16 23:32 ---
Subject: Bug 25106
Author: kargl
Date: Fri Dec 16 23:32:29 2005
New Revision: 108692
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108692
Log:
2005-12-10 Steven G. Kargl [EMAIL PROTECTED]
PR fortran
--- Comment #4 from kargl at gcc dot gnu dot org 2005-12-16 23:34 ---
I'll commit to 4.1 in a few days.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25461
--- Comment #1 from kargl at gcc dot gnu dot org 2005-12-17 05:17 ---
Note, this is with a gmake bootstrap in a clean directory.
There are no local modification of configure* files in my tree.
mkdir obj
cd obj
../gcc4x/configure --prefix=$HOME/work/4x --disable-libmudflap \
--enable
--- Comment #2 from kargl at gcc dot gnu dot org 2005-12-17 05:25 ---
One more note. I used svn swtch to remove the java and libjava sources
from my local tree to free up space. Not knowing what fastjar is, I left
it in place.
I also restarted a build from scratch to get a copy
--- Comment #1 from kargl at gcc dot gnu dot org 2005-12-17 14:06 ---
Patch at
http://gcc.gnu.org/ml/fortran/2005-12/msg00375.html
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from kargl at gcc dot gnu dot org 2005-12-17 14:07 ---
Confirmed.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from kargl at gcc dot gnu dot org 2005-12-17 17:30 ---
Subject: Bug 25458
Author: kargl
Date: Sat Dec 17 17:30:26 2005
New Revision: 108720
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108720
Log:
PR fortran/25458
* simplify.c (gfc_simplify_ibset
--- Comment #4 from kargl at gcc dot gnu dot org 2005-12-17 17:46 ---
I'll commit the patch to 4.1 in a few days, and then
I'll close this PR.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25486
--- Comment #1 from kargl at gcc dot gnu dot org 2005-12-19 01:00 ---
I just bootstrapped 4.1 and the regression is also in 4.1!
I believe it appeared after 27 Nov 05 in that my older 4.1
gfortran, which wokred correctly, had that timestamp.
--
kargl at gcc dot gnu dot org changed
--- Comment #2 from kargl at gcc dot gnu dot org 2005-12-19 04:33 ---
This regression is caused by
svn update -r 107850 on 4.1
svn update -r 107745 on trunk.
This a patch I committed, but until my hard drive is replaced I
won't be able to revert without too much pain. If anyone else
--- Comment #22 from kargl at gcc dot gnu dot org 2005-12-20 17:01 ---
The testcase isn't needed and should not be committed.
As explained elsewhere, the problem was caused by merging
one line from a 4.1 patch into 4.0 that should not have
been committed. Jerry has fixed that problem
--- Comment #5 from kargl at gcc dot gnu dot org 2005-12-20 18:15 ---
Subject: Bug 25458
Author: kargl
Date: Tue Dec 20 18:15:19 2005
New Revision: 108861
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108861
Log:
2005-12-20 Steven G. Kargl [EMAIL PROTECTED]
Tobias
--- Comment #15 from kargl at gcc dot gnu dot org 2005-12-21 20:21 ---
(In reply to comment #14)
I tried to run the
fortran testsuite with make check-gfortran, but check-gfortran is not
in the
makefile. It would be nice if just fortran testsuite could be run.
Dale, move
--- Comment #6 from kargl at gcc dot gnu dot org 2005-12-24 17:42 ---
Fixed on 4.1 and 4.2.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from kargl at gcc dot gnu dot org 2005-12-31 18:55 ---
Subject: Bug 25055
Author: kargl
Date: Sat Dec 31 18:55:30 2005
New Revision: 109199
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109199
Log:
2005-12-31 Steven G. Kargl [EMAIL PROTECTED]
PR fortran
--- Comment #8 from kargl at gcc dot gnu dot org 2005-12-31 18:55 ---
Subject: Bug 25106
Author: kargl
Date: Sat Dec 31 18:55:30 2005
New Revision: 109199
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109199
Log:
2005-12-31 Steven G. Kargl [EMAIL PROTECTED]
PR fortran
--- Comment #6 from kargl at gcc dot gnu dot org 2005-12-31 19:04 ---
fixed.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from kargl at gcc dot gnu dot org 2005-12-31 19:05 ---
Fixed in 4.1 and trunk. This will not be fixed (by me)
in 4.0.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2006-01-02 17:03 ---
I have a patch.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #4 from kargl at gcc dot gnu dot org 2006-01-02 22:23 ---
Subject: Bug 24640
Author: kargl
Date: Mon Jan 2 22:23:35 2006
New Revision: 109246
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109246
Log:
PR fortran/24640
* parse.c (next_free): Check for whitespace after
--- Comment #5 from kargl at gcc dot gnu dot org 2006-01-02 22:24 ---
Committed to trunk. Patch will be committed to 4.1 in a day or two.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2006-01-02 23:38 ---
I have a patch for this.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from kargl at gcc dot gnu dot org 2006-01-03 22:01 ---
Subject: Bug 25101
Author: kargl
Date: Tue Jan 3 22:01:10 2006
New Revision: 109288
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109288
Log:
2006-01-03 Steven G. Kargl [EMAIL PROTECTED]
PR fortran
--- Comment #5 from kargl at gcc dot gnu dot org 2006-01-03 22:02 ---
Fixed on trunk. I'll commit to 4.1 in a day or two.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from kargl at gcc dot gnu dot org 2006-01-06 20:04 ---
Subject: Bug 25101
Author: kargl
Date: Fri Jan 6 20:04:15 2006
New Revision: 109425
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109425
Log:
2006-01-06 Steven G. Kargl [EMAIL PROTECTED]
PR fortran
--- Comment #7 from kargl at gcc dot gnu dot org 2006-01-06 20:04 ---
Subject: Bug 24640
Author: kargl
Date: Fri Jan 6 20:04:15 2006
New Revision: 109425
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109425
Log:
2006-01-06 Steven G. Kargl [EMAIL PROTECTED]
PR fortran
--- Comment #8 from kargl at gcc dot gnu dot org 2006-01-06 20:06 ---
Fixed on 4.1, too.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #7 from kargl at gcc dot gnu dot org 2006-01-06 20:07 ---
Fixed on 4.1, too.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from kargl at gcc dot gnu dot org 2006-01-07 06:05 ---
Please, do not use non-standard documents! You can get a copy
of the Final Committee Draft of the Fortran 2003 standard from
the J3 web site (or you can ask me to send you a copy). Vendors
tend to interpret
--- Comment #2 from kargl at gcc dot gnu dot org 2006-01-07 17:39 ---
BTW, this feature is actively being worked upon. See
http://gcc.gnu.org/ml/fortran/2005-12/msg00270.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25709
--- Comment #5 from kargl at gcc dot gnu dot org 2006-01-07 20:19 ---
Andrew, Lahey's code checking utility gives
Compiling program unit f at line 1:
Compiling program unit test at line 5:
Encountered 0 errors, 0 warnings, 0 informations in file SOURCE.F90.
Compiling file SOURCE.F90
--- Comment #9 from kargl at gcc dot gnu dot org 2006-01-07 21:55 ---
(In reply to comment #8)
Not all of the underlying are just g77 features. Some like 18540/25705 are
legal f90, f95, f06 code an just calling them excremental is unprofessional.
This diminishes the 90% plus
--- Comment #7 from kargl at gcc dot gnu dot org 2006-01-12 05:25 ---
See 14.1.2.1.
A common block name in a scoping unit also may be the name of any local
entity other than a named constant, intrinsic procedure, or a local variable
that is also an external function
--- Comment #5 from kargl at gcc dot gnu dot org 2006-01-12 20:18 ---
The following simple patch
Index: parse.c
===
--- parse.c (revision 109606)
+++ parse.c (working copy)
@@ -349,8 +349,10 @@ next_free (void
--- Comment #7 from kargl at gcc dot gnu dot org 2006-01-12 22:42 ---
I have a patch.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #8 from kargl at gcc dot gnu dot org 2006-01-13 19:58 ---
Technically, all of the transformations noted by Joost are
a violation of the Fortran standard with the possible
exception of the transformation of x**(1./3.) to cbrt(x).
See 7.1.7.2.
--
kargl at gcc dot gnu dot
--- Comment #8 from kargl at gcc dot gnu dot org 2006-01-13 21:09 ---
Subject: Bug 25756
Author: kargl
Date: Fri Jan 13 21:09:24 2006
New Revision: 109674
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=109674
Log:
2006-01-13 Steven G. Kargl [EMAIL PROTECTED]
PR fortran
--- Comment #9 from kargl at gcc dot gnu dot org 2006-01-13 21:10 ---
Committed the fix to trunk. I'll wait a few days for 4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25756
--- Comment #4 from kargl at gcc dot gnu dot org 2006-01-17 00:02 ---
I have a patch
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kargl at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25813
--- Comment #3 from kargl at gcc dot gnu dot org 2006-01-22 00:46 ---
It looks like one or more of pault's patchs has fixed this problem.
kargl[209] gfc4x -c pr24327.f90
In file pr24327.f90:4
function foo ()
1
In file pr24327.f90:2
real :: foo
2
Error
--- Comment #1 from kargl at gcc dot gnu dot org 2006-01-22 00:56 ---
Andrew,
Are you sure? NAG's compiler compiles the code, as does gfortran.
Lahey's checker when I gave it the code gives
Lahey/Fujitsu Fortran 95 Source Check Output
Compiling program unit a at line 1:
Encountered
--- Comment #7 from kargl at gcc dot gnu dot org 2006-01-22 01:06 ---
Closing as fixed. The (duplicate?) PR pointed to by Richard has
been fixed, and the originator of this bug report has not supplied
the code as requested by Andrew on 10/30/05.
--
kargl at gcc dot gnu dot org
--- Comment #2 from kargl at gcc dot gnu dot org 2006-01-22 19:18 ---
Here's the back trace.
#0 gfc_free_namespace (ns=0x861d800) at ../../gcc4x/gcc/fortran/symbol.c:2361
#1 0x0808a292 in free_sym_tree (sym_tree=0x8616560)
at ../../gcc4x/gcc/fortran/symbol.c:2328
#2 0x0808a2e3
--- Comment #6 from kargl at gcc dot gnu dot org 2006-01-27 19:11 ---
I working on a patch for this.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from kargl at gcc dot gnu dot org 2006-01-30 00:52 ---
WONTFIX works for me. As you originated the PR, I'll you close it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22495
--- Comment #3 from kargl at gcc dot gnu dot org 2006-01-30 18:42 ---
For a reduced testscase see
http://gcc.gnu.org/ml/fortran/2006-01/msg00407.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
--- Comment #2 from kargl at gcc dot gnu dot org 2006-02-02 19:12 ---
Subject: Bug 25072
Author: kargl
Date: Thu Feb 2 19:11:58 2006
New Revision: 110517
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110517
Log:
2006-02-02 Steven G. Kargl [EMAIL PROTECTED]
PR fortran
--- Comment #6 from kargl at gcc dot gnu dot org 2006-02-02 19:12 ---
Subject: Bug 24958
Author: kargl
Date: Thu Feb 2 19:11:58 2006
New Revision: 110517
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110517
Log:
2006-02-02 Steven G. Kargl [EMAIL PROTECTED]
PR fortran
--- Additional Comments From kargl at gcc dot gnu dot org 2005-07-08 21:01
---
I've committed FX's mainline change to dev_null.f90 that causes this
test program to only be compiled on linux and solaris to the
4.0 branch.
Andrew, is this sufficient to close this PR? The behavior
--- Additional Comments From kargl at gcc dot gnu dot org 2005-07-08 21:25
---
Back port to 4.0
--
What|Removed |Added
Status|NEW
--- Additional Comments From kargl at gcc dot gnu dot org 2005-07-08 21:26
---
Back ported to 4.0
--
What|Removed |Added
Status|NEW
--- Additional Comments From kargl at gcc dot gnu dot org 2005-07-08 21:26
---
Back ported to 4.0
--
What|Removed |Added
Status|NEW
--- Additional Comments From kargl at gcc dot gnu dot org 2005-07-18 17:15
---
This should be fairly straight forward to implement. The
question is where do we put the module and 8.o file. Is
${prefix}/lib/modules a good enough place? There is also
the possibility of ${prefix
--- Additional Comments From kargl at gcc dot gnu dot org 2005-07-22 18:45
---
There is an amazing amount of detail missing from this PR.
Unless Weon Kim supplies the actual errors encountered, the
compiler flags, and some details of the build procedure
followed, this PR can be closed
--- Additional Comments From kargl at gcc dot gnu dot org 2005-07-25 21:41
---
So, GNU does not follow IEEE Std 1003.1, 2004?
gfortran.h contains
#include limits.h
#ifndef PATH_MAX /* This is defined in a IEEE Std 1003.1, 2004 */
# include sys/param.h
# define PATH_MAX
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-01 16:43
---
Posix says:
Pathname Variable Values
The values in the following list may be constants within an
implementation or may vary from one pathname to another. For
example, file systems or directories may
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-05 22:52
---
The code appears to be illegal. Lahey reports
Compiling program unit consts_test at line 1:
1034-S: SOURCE.F90, line 10: Right parenthesis missing or position of right
parenthesis invalid.
1034-S
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-06 02:38
---
gfortran is doing the right thing according to section 7.1.6.1
of the Fortran 95 standard. For completeness, here is the output
of NAGWare F95 compiler.
kargl[204] f95 -kind=byte -c lk.f90
Error: lk.f90
--
Bug 20585 depends on bug 22390, which changed state.
Bug 22390 Summary: Implement FLUSH statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22390
What|Old Value |New Value
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-07 23:04
---
I've committed the patch to mainline. This is an enhancement,
so it is inappropriate for the 4.0 branch (ie. it doesn't fix
a regression).
--
What|Removed |Added
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-10 20:19
---
I suggest running the code through ftnchek and fixing potential
problems. These looks suspicious
Warning in module MAIN in file show_bug.f: Variables used before set
IDATWR used at line 15 file
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-11 22:33
---
Dale, I've compiled your new code with both 4.0 and 4.1 with -O0, -O1, -O2,
and -O3. It runs and a comparison of the output shows the results that
you expect. How old is your version(s) of gfortran? Can
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-12 22:16
---
How old is your version of gfortran? I can compile your example with
troutmask:sgk[220] gfc41 --version
GNU Fortran 95 (GCC 4.1.0 20050811 (experimental))
troutmask:sgk[221] gfc --version
GNU Fortran 95
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-14 01:33
---
(In reply to comment #1)
This is a mingw32 specific issue.
The implemention for mingw32 is not complete.
intrinsics/cpu_time.c is where it is implemented,
we only check for HAVE_GETRUSAGE and HAVE_TIMES
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-14 16:48
---
(In reply to comment #3)
I don't know why you say that MingW claims to have a HAVE_TIMES.
It doesn't.
Read the code for __cpu_time_1. The only way that cpu_time can return
zero is if HAVE_TIMES
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-15 17:03
---
I think this many be a duplicate of PR 21820. Also, there
has been some discussion in the fortran@ list about gfortran's
(homebrewed) internal buffering. FWIW, if you have pre-existing
files that you want
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-22 16:47
---
IMAG() is neither a generic intrinsic procedure nor a specific
intrinsic procedure. You want AIMAG() or you need to explicitly
declare IMAG() and provide a function.
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-23 21:18
---
Confirmed.
gfortran's error reporting and recovery mechanism appears to lead
to hopeless confusion within the scanner/parser whereby it gets
stuck in an infinite loop.
--
What|Removed
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-23 21:38
---
Can you compile this code with any modern compiler? I used
fsplit to split the code into a set of files that contains
exactly one subprogram per file. Of the 54 *.f files that I
get from fsplit, only 25
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-24 17:54
---
Changing the * in the format statements and the encode/decode statements
may help prevent gfortran from getting stuck, but there are several other
nonstandard statements in the code.
To deal with gfortran
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-11 22:05
---
(In reply to comment #5)
Furthermore, when one writes binary in C, you get exactly what your variables
are sized to in your code. If the platform is a 32 bit machine and is IEEE
compliant,
What happens
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-12 00:35
---
(In reply to comment #7)
I realize that disagreeing with the assumptions made during the design may be
regarded by some as rants, but what I was attempting to do (perhaps poorly)
is
illustrate why
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-12 21:54
---
Confirmed. Lahey's web-based checker also accepts the code.
--
What|Removed |Added
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-15 00:15
---
(In reply to comment #0)
consider the following program
program random
implicit none
real :: x
call random_seed();
call random_number(x);
write(*,*) x
end program random
When I run this program
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-16 02:01
---
gfc_simplify_radix is used in intrinsic.c for simplification of the
RADIX intrinsic function. The standard defines RADIX for REAL and
INTEGER. See 13.14.84.
program mn
complex z
print*, radix(z)
end
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-16 02:34
---
I'm not sure what this function is really accomplishing. The
line *dest = *src; isn't copying src to dest. We simply
have set *dest to point to src. So, the for loop is a NOP.
Of course, I could
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-16 16:09
---
Switch Severity to enhanacement (although I disagree the basic premise).
--
What|Removed |Added
--- Additional Comments From kargl at gcc dot gnu dot org 2005-09-16 18:46
---
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01004.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23516
301 - 400 of 1396 matches
Mail list logo
