--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-03
10:34 ---
Partial fix proposed here: http://gcc.gnu.org/ml/fortran/2005-03/msg00023.html
This fixes the bug when writing to files, but there still is the case of
preconnected units (stdout, stderr
--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-03
10:37 ---
Hi,
I see this patch hasn't been commited yet, could you please send it again to the
mailing-lists? With the new approval rules, maybe it should hopefully get
reviewed...
--
http://gcc.gnu.org
--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-03
13:08 ---
Complete patch is here: http://gcc.gnu.org/ml/fortran/2005-03/msg00024.html
Note: this just makes the limit higher (1 Gb), but there still is a limit on the
size of things you can write to preconnected
--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-02
09:34 ---
It happens for all kind of output (formatted (direct or sequential) or
unformatted), and is due to gfortran setting an arbitrary maximal length of
1 chars (this is in current_unit-recl). Since
--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-02
10:31 ---
I agree with Steve's comment on this. As I am currently digging into the I/O
library, I need to know if it's worth working on this one. Knowing that many
commercial compilers (Intel, Portland, Sun) issue
--- Additional Comments From coudert at clipper dot ens dot fr 2005-03-01
13:10 ---
This has indeed nothing to do with the output being redirected to a file, or
stdout, or even being connected (in Fortran way) to a file:
$ cat pr20257.f90
integer, parameter :: NX = 32, NR = 16, NPHI
--
What|Removed |Added
CC||coudert at clipper dot ens
||dot fr
http://gcc.gnu.org
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-27
15:54 ---
Patch submitted: http://gcc.gnu.org/ml/fortran/2005-02/msg00362.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20101
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-27
16:01 ---
Portland, Sun, Intel and SX compilers does it with no leading blank. MIPSpro
compiler is the only I could find that puts leading blanks.
--
What|Removed |Added
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-27
17:32 ---
Proposed patch: http://gcc.gnu.org/ml/fortran/2005-02/msg00374.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18025
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-27
21:45 ---
I believe this bug, PR 20092 and PR 20131 are duplicates. We will be sure when
they get fixed, but I mention this here for the record.
I may not have time to work on this before a few weeks
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-25
19:50 ---
I'm no language lawyer, but this works (returns two zeros and no error) for Sun,
PGF, IBM, MIPSpro and Intel compilers. I think this should be considered as a
bug (I confirm it is still present in CVS
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-24
13:46 ---
I submitted a patch to fix this bug. See
http://gcc.gnu.org/ml/fortran/2005-02/msg00303.html
--
What|Removed |Added
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-24
16:24 ---
$ cat pr20124.f
x = -.01
y = .01
write(*,'(2f10.2)') x, y
print *, x, y
end
$ ./bin/gfortran -static pr20124.f ./a.out
0.00 0.00
-9.998E-03 9.998E-03
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-24
17:38 ---
Patch proposed in http://gcc.gnu.org/ml/fortran/2005-02/msg00315.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20124
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-22
10:33 ---
This is really weird:
$ cat a.f90
integer :: i
open (unit=20, file='data')
read(20,*) i
write(*,*) ' foo '
backspace(20)
read(20,*) i
end
$ cat data
1
2
3
$ gfortran a.f90 ./a.out
foo
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-22
10:39 ---
I can't reproduce the behaviour reported. All I see is that gfortran is ignoring
the $ character:
$ cat a.f90
program testRead
implicit none
print '(a,$)','hello world'
print
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-21
14:21 ---
Same happens with kind=10 on i686-linux-gnu:
real(10) :: a, b
b = sqrt(a)
end
From gfc_get_intrinsic_lib_fndecl:
if (ts-type == BT_REAL)
{
switch (ts-kind)
{
case 4
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-21
16:34 ---
gfortran seems to handle incorrectly the case when we ask for more integers than
we provide (Intel compiler, for example, set j and k to 0 in the following
case). Reduced testcase:
$ cat a.f
--
What|Removed |Added
CC||coudert at clipper dot ens
||dot fr
http://gcc.gnu.org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20005
--- Additional Comments From coudert at clipper dot ens dot fr 2005-02-10
22:28 ---
Could this one be closed?
slmac1.f from the LAPACK library is designed to be compiled without any
optimization (it's stated in the FAQ and everywhere). Infinite loop is what is
expected to happen when
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28
10:37 ---
It seems that, above a given size, gfortran declares the array as non-static:
$ cat a.f90
program kk
implicit none
integer, parameter :: N=32768**2
real, dimension(N) :: input
call random_number
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28
11:49 ---
As always with modules, reducing is indeed painful. There are already many bugs
reported with modules and gfortran (some of them even very basic), and this
could probably be one of those. Unless you have
--
What|Removed |Added
CC||coudert at clipper dot ens
||dot fr
http://gcc.gnu.org
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28
12:19 ---
Did you try to compile this file without optimization (as is indicated in:
http://www.netlib.org/lapack/faq.html#1.26)? The code in the ?lam*.f files is
used to determine the machine precision (which
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28
14:59 ---
I think this is a duplicate of PR16861 (probably the most annoying bug on
scientific codes these days, since they do use modules a lot).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19669
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-28
17:20 ---
(reply to comments #3 and #4)
The print statement in the code induces I/O, which in some sense disrupt the
flow of code and has the effect of making unaware of possible optimizations. I
can't offer
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-26
09:08 ---
The same bug happens with aimag (and, as far as I can see, for the same
reasons):
$ cat a.f90
program bug
implicit none
complex(8) x
write(*,*) aimag(x)
end
$ gfortran -std=f95 a.f90
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-26
19:23 ---
Compiling with -std=f95, you can also get these errors:
Error: Type of argument 'x' in call to 'cos' at (1) should be REAL(4), not
COMPLEX(8)
Error: Type of argument 'x' in call to 'exp' at (1) should
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-24
07:30 ---
I confirm comment #3: PR 17675 is fixed, but this bug still appears on the
nightly test logs I do on sparc-sun-solaris2.9. Bug or not, this should be fixed
(either the compiler or the testcase).
I
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot
: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19575
: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19576
: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19543
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-19
12:37 ---
As this bug is blocking some of my code, I did some testing of the patch
provided in comment #2. Bootstrapped and no additional regression on
sparc-sun-solaris2.9. It fixes the testcase all right. Thanks
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-19
12:38 ---
I tested the patch from comment #8. Bootstrapped and regtested on
sparc-sun-solaris2.9. This fixes the intrinsic_transpose.f90 failure all right.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19294
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-18
13:10 ---
I confirm this issue is still present as of 2005-01-18. As a important number of
people here, this is blocking my code from compiling smoothly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16861
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-17
12:23 ---
I see that one to (on i686-linux and sparc-solaris).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19479
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19481
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-17
17:09 ---
I worked around this bug, commenting a line in /mingw/include/math.h (I quote it
here for reference):
//_CRTIMP double __cdecl cabs (struct _complex);
The end of the compilation runs smoothly, but when
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-10
09:53 ---
Currently, the main problem with building for AIX5.1 is that TOC for cc1 and
f951 are too big for the linker to handle. Extra flags must be used:
-Wl,-bbigtoc and -mminimal-toc, that the configure
: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19362
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-09
14:47 ---
I think this bug and PR15266 are really about the same thing: getting the
configure system to handle the complex libraries on IRIX. Would there be any
chance to get one of them resolved as DUPLICATE
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-09
15:02 ---
More detail on this one: it fails to build mips-sgi-irix6.5/32/libgfortran but
compilation of mips-sgi-irix6.5/64/libgfortran works fine. The second case, the
output of the step building exp_c8.c
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-09
16:50 ---
Reduced case (from FP19335) still fails on powerpc-darwin with Tobias' patch.
The output from gfortran -fdump-tree-gimple (I hope this was the right thing to
do) is the same with and without -fmerge
at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.7.0
GCC host triplet: powerpc-apple-darwin7.7.0
GCC target triplet: powerpc-apple-darwin7.7.0
http://gcc.gnu.org/bugzilla
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-07
12:30 ---
(reply to comment #4)
After your comment, not sure either if it's a bug. The original testcase
(intrinsic_nearest.f90) fails with Intel (7 and 8) and Portland Group compilers
on i686, but works with g95
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-06
15:56 ---
The reduced case given in comment #9 fails to compile with Intel compiler (This
entity cannot be in a specification expression), Sun (Local variable M must
be a dummy argument or in common to be used
gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19294
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-06
21:52 ---
Playing with this test case to produce a minimal example, I found lots of
differents sources that crash at runtime, for different levels of optimization
(some at 1 and 2 but not 0 and 3, some only for 0
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-06
23:12 ---
Debugging with puts statements, I confirm that the previously isolated code is
the place where the segfault happens. Replacing:
*rptr = *sptr;
with:
puts (Before); foo = *sptr
: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-07
00:16 ---
As of today, libgfortran compilation fails on mips-sgi-irix6.5 with:
../../../../gcc/libgfortran/generated/exp_c8.c:29: error: conflicting types for
'cabs'
/var/tmp/gfortran-20050106/ibin/gcc/include
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-01
12:28 ---
No problem as of 2005-01-01, 04:00 MET, with nothing changed in the scripts.
Probably a
temporary problem on my side. Sorry!
PS: marked bug as resolved - WORKSFORME, I hope it was the right thing
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun-solaris2.9
GCC host triplet: sparc-sun-solaris2.9
GCC target triplet: sparc-sun-solaris2.9
http
: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc-sun
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18778
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
http
--- Additional Comments From coudert at clipper dot ens dot fr 2004-12-01
12:50 ---
This is probably the reason why the NIST tests FM108 and FM411 are failing.
--
What|Removed |Added
use of external keyword
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
Version: 4.0.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: coudert at clipper dot ens dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC
64 matches
Mail list logo
