--- Comment #21 from Thomas dot Koenig at online dot de 2006-05-27 20:24
---
Subject: Re: [meta-bug] g77 features lacking in gfortran
sgk at troutmask dot apl dot washington dot edu wrote:
> 27757 does not belong in this meta-bug. It is actually
> a regression with respec
--- Comment #11 from Thomas dot Koenig at online dot de 2007-02-28 23:13
---
Subject: Re: a ** exp fails for integer exponents if exp is "-huge()-1"
(endless loop)
> --- Comment #10 from pinskia at gcc dot gnu dot org 2007-02-28 22:39
> ---
> Yes declar
--- Comment #5 from Thomas dot Koenig at online dot de 2007-03-09 20:13
---
Subject: Re: [4.3/4.2 regression] Runtime error on legal code using RECL
> I believe I have a fix. I am testing now. We were not initializing a few
> things when we have a record length given.
>
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-16
12:41 ---
I think I have identified the problem.
The hang itself is probably caused by a Lapack bug, because slarrb is
only fed 0. and NaN as arguments.
The reason why this is so is probably due to a problem in
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-16
20:51 ---
Checking this on i686-unknown-linux-gnu, I find the same
result with flag_complex_method=2 as on ia-64. I am also
seeing the same result with logarithmic scaling (using frexp and
ldexp). Maybe I&#
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-17
09:42 ---
(In reply to comment #7)
> Using Mathematica I get for
> (10^20 + 10^12 I)/(1 - 10^-8) = 10^20 + 2 * 10^12 I
>
> so really neither of them are mathematically correct.
The test case was (1
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-17
13:52 ---
Another datapoint - the fact that slarrb "has problems"
has been confirmed by a Lapack developer. A new version is
slated to appear as a patch soon. Hopefully, this will reduce
the potenti
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-18
10:42 ---
I think this is identical to PR 15332.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20037
ith: ../gcc/configure --prefix=/home/ig25 --enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050219 (experimental)
--
Summary: reshape of pointer array segfaults at runtime
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: no
--
What|Removed |Added
CC||Thomas dot Koenig at online
||dot de
http://gcc.gnu.org
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
12:28 ---
I'll check later wether this is fixed with the proposed fix
for PR 19568 to be found at
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02295.html
Thomas
--
What|Re
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
21:27 ---
No, this isn't fixed with the patch I referred to earlier.
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20131
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
22:54 ---
Add "fflush(stdout);" at the end of cio.c, and things work
as expected.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
23:09 ---
This is two bugs.
The first bug can be reduced to
$ cat open-opt.f
open(unit=10,status="scratch ")
end
$ gfortran open-opt.f
$ ./a.out
At line 1 of file open-opt.f
Fortran run
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
23:29 ---
This has a pretty good chance of fixing it.
Proper testing, Changelog entry, ... tomorrow.
Index: string.c
===
RCS file: /cvsroot/gcc
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-26
20:46 ---
Patch for the first bug here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01694.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20163
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-26
20:49 ---
Here is a reduced test case for the second error:
$ cat open-after-error.f
open(10,status="foo",err=100)
call abort
100 continue
open(10,status="scratch")
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-27
12:52 ---
Is this really fixed?
Look at this:
$ cat c-div.c
#include
#include
int main()
{
float a;
complex float b,c;
foo(&a,&b);
c = b/a;
return creal(c) + cimag(c) < 0;
}
$
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-28
20:55 ---
Comment #7 shows that there is still something to be done
for (br+I*bi)/a (with real br, bi, a). This could be
simplified to br/a + I*bi/a, which isn't happening.
Thomas
--
--
Bug 18902 depends on bug 19953, which changed state.
Bug 19953 Summary: Special-case real + complex arithmetic operation
(-ffast-math)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
What|Old Value |New Value
--
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-28
20:55 ---
What I meant was comment#8 *sigh*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-28
21:58 ---
(In reply to comment #11)
> For me I get:
> D.1542 = COMPLEX_EXPR / SR.4, IMAGPART_EXPR / SR.4>;
> D.1541 = D.1542;
> D.1500 = D.1541;
> return (double) REALPART_EXPR + (dou
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-01
15:43 ---
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #11)
> I get the same as I got above with the following version on x86:
> GNU C version 4.0.0 20050225 (expe
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-01
21:07 ---
Andrew,
I'm sorry if I'm not making myself clear here.
The problem that I see is that, on ia64-unknown-linux-gnu and on
i386-pc-linux-gnu, with clean trees, I see code like
:;
D.2390 = 0
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-01
21:26 ---
(In reply to comment #18)
> > :;
> > D.2390 = 0.0 / SR.22;
> > D.2392 = SR.22 + D.2390 * 0.0;
> > c$real = (D.2371 + D.2372 * D.2390) / D.2392;
> > c$imag = (D.23
gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20278
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-03
20:27 ---
Same thing on i686:
$ gfortran write-many.f
$ time ./a.out
real0m5.576s
user0m5.508s
sys 0m0.038s
$ g77 write-many.f
$ time ./a.out
real0m3.252s
user0m3.185s
sys 0m0.041s
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-04
10:47 ---
This is really _very_ inefficient, by a factor of 20.
Some test numbers:
$ g77 write-record.f
$ time ./a.out
real0m1.819s
user0m1.774s
sys 0m0.044s
$ gfortran write-record.f
$ time
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-06
23:34 ---
Updated patch:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00566.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19568
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-06
23:34 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00566.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20131
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08
08:20 ---
Updated patch:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00729.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20131
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08
08:21 ---
Updated patch:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00729.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19568
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08
15:35 ---
Here's a somewhat reduced testcase that fails
for me on ia64-unknown-linux-gnu:
$ cat forall_5.f90
program evil_forall
implicit none
type t
logical valid
integer :: s
integer, dime
3,12329,12343,12347,12373,12377,12379,12391,12401, &
12409,12413,12421,12433,12437,12451,12457,12473,12479,12487, &
12491,12497,12503,12511,12517,12527,12539,12541,12547,12553 /)
integer, dimension(1500), parameter, public :: &
allprimes=(/ primes_1_to_300, primes_301_to_600, primes_601_to_900, &
primes_901_to_1200, primes_1201_to_1500 /)
contains
end module bug04
--
Summary: ICE in gfc_conv_array_initializer
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20387
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08
20:30 ---
On i686-pc-linux-gnu, forall_5.f90 does the following:
$ gfortran forall_5.f90
$ ./a.out
Fortran runtime error: Attempt to allocate a negative amount of memory.
$ gfortran -v
Using built-in specs
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-09
15:13 ---
$ cat eoshift.f90
print *,eoshift((/1, 3/), 3)
end
$ gfortran eoshift.f90
$ ./a.out
Segmentation fault
This fails because the loop
for (n = 0; n < len; n++)
{
memcpy (d
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-09
16:01 ---
The complaint is a segfault at runtime when
you actually want to do anything with the
string whose length depends on a missing
optional argument. This isn't too bad (the
same thing happens i
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-09
23:33 ---
This looks very much like a front end bug. The
"along" parameter gets the wrong value.
Look at this:
$ cat test_spread.f90
program test_spread
implicit none
integer, parameter :
P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20432
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11
21:21 ---
My vote would go for "fixing" this, because of the NIST
testsuite failure.
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11
21:36 ---
(In reply to comment #1)
> D.2395 * 0.0
> Can trap if D.2395 is a non quiet NAN.
D.2395 gets its value from
D.2395 = SR.23 / SR.24;
two lines earlier. Is there anything that would gene
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11
21:59 ---
There are two strange things here:
- Why the + 0. ?
- Why the casts to double?
--
What|Removed |Added
--
Summary: pessimization of complex expression
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thoma
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11
22:49 ---
> > - Why the casts to double?
> Because that is required by the C standard.
Isn't that covered by the as-if rule? I'm fairly
sure the cast to double won't change the re
CONFIRMED
Severity: normal
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20437
ith --enable-maintainer-
mode
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20438
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-12
09:45 ---
(In reply to comment #4)
> (In reply to comment #3)
> > > > - Why the casts to double?
> > > Because that is required by the C standard.
> >
> > Isn't th
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-12
22:52 ---
The 0 as data pointer is a signal to the library that it
needs to fill out the properties of the array, because
the front end can't determine it.
See
http://gcc.gnu.org/ml/fortran/2005-03/msg
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-12
23:13 ---
(In reply to comment #6)
> Well the real reason is creal/cimag returns double and not float.
> Use crealf/cimagf instead.
You're right, of course. Doing that gets me
:
foo (&cr, &a
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-13
21:10 ---
I believe this is also fixed with
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00729.html
Copyright papers, where are you? :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20092
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-13
22:11 ---
Patch here:
http://gcc.gnu.org/ml/fortran/2005-03/msg00232.html
--
What|Removed |Added
--
What|Removed |Added
BugsThisDependsOn||19106
AssignedTo|unassigned at gcc dot gnu |Thomas dot Koenig at online
|dot org
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20517
--
What|Removed |Added
Keywords||missed-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20517
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-17
13:41 ---
(In reply to comment #3)
> I cannot remember the rules but -0.0 * 0.0 could be -0.0 (and not 0.0),
someone needs to help me
> here.
I'm trying to see what input could apply to, but I can
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-17
14:40 ---
(In reply to comment #2)
> The patches suggested in comment #2 under bug 20156 fixes bugs 20156, 20125
> and
> 20471 on the macintosh and does not seem to cause any new problems.
Can you su
--
Summary: unnecessary operations in tailcall
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy:
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-19
13:20 ---
(In reply to comment #8)
> Due to general gfortran lameness only contained functions are ever inlined.
> Top-level functions are never inlined.
Why?
I've worked with a Fortrtran 77 co
: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
--
What|Removed |Added
OtherBugsDependingO||19292
nThis||
Severity|normal |enhance
nedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20618
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-24
14:29 ---
Actually, implementing this would be a bit harder
than I thought.
It seems that the variable expression is evaluated
at runtime, so you can do things like
$ cat v-fmt2.f
program main
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-29
15:11 ---
I'll try and have a look.
Hopefully, my copyright papers that I sent off on 2005-03-19 will
come through sometime soon, because the end-of-record patch
at http://gcc.gnu.org/ml/gcc-patches/20
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-01
11:45 ---
No write or print statement is necessary:
$ cat assign.f90
program main
assign 1000 to i
1000 format (A)
end
$ gfortran assign.f90
$ gfortran -fdump-parse-tree assign.f90
In file
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-01
13:34 ---
This patch fixes the test case. It also includes my
EOR patch for advancing I/O.
This is regression-tested on mainline. I'll submit a proper
patch when I have finished regression-testing it o
Summary: size= isn't implemented correctly
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig
--
What|Removed |Added
Keywords||wrong-code
Known to fail||4.0.0 4.1.0
http://gcc.gnu.org/bugzilla/show_bug.c
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-05
06:40 ---
This is the same bug as the first half of 20163, which
is fixed with
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01694.html
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20749
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-05
07:17 ---
This is fixed with
http://gcc.gnu.org/bugzilla/attachment.cgi?id=8525&action=view
(an attachment to PR 20661).
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20744
dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20783
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-06
14:21 ---
This goes away when --disable-checking is specified for 4.0
and 4.1.
Closing as invalid.
--
What|Removed |Added
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-08
07:36 ---
Subject: Re: Function entries and entries with alternate returns not
implemented
You wrote (in bugzilla):
> - We tried out the designed successor and found it very immature. In fact
> it
ED
Severity: minor
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19021
--
What|Removed |Added
Keywords||ice-on-invalid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19021
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19032
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-16
11:47 ---
The code runs correctly on IA-64.
$ gfortran fft2.for
$ ./a.out
0.00 0.00
0.00 0.00
4.00 0.00
0.00 0.00
0.00 0.00
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-16
15:59 ---
I reran the tests with the 20041114 snapshot at -O1, and
the segfault did indeed go away, so this is a regression.
Quite likely, this is a IA-64 target problem.
--
http://gcc.gnu.org/bugzilla
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-16
22:40 ---
Reals are also broken:
$ cat mod-real.f90
program main
real :: a,b
a = 2.0
b = -1.0
print *,modulo(a,b)
end program main
$ gfortran mod-real.f90
$ ./a.out
-1.00
--
http://gcc.gnu.org
nu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19052
--
What|Removed |Added
Version|unknown |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19052
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-17
09:30 ---
With 20041121, there was a problem with
xeigtstc hanging with -O1 on IA-64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-17
14:27 ---
I've adjusted the subject.
I've had a look at the real modulo and mod case,
but didn't quite understand it - it appeared to
be overly complicated, compared to the straightforward
formul
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-17
19:32 ---
The assertion failure happens for me on
an i686-pc-linux-gnu, as well. Looks like
different bugs on different architectures for
the same test case. (The assertion failure
is a bug, too!)
--
http
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-12
10:42 ---
(In reply to comment #2)
> Speculations I'd put money on if the bookies would accept it:
> 1) You can show this same problem with C/C++ if you have enough cases.
Yes.
$ time ./multi-ca
r with many
arithmetic if statements
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot
ptor
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18955
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18958
: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18959
: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18960
2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18966
em.
--
Summary: LAPACK test xeigtsts segfaults
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig
0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18982
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-14
16:13 ---
... I forgot to add, on a ia64-unknown-linux-gnu running
RedHat ES 3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-15
08:45 ---
(In reply to comment #1)
> I think that's what intended
That's what's for discussion :-)
> g77 behaves the same way.
I think this is a bug, too.
My thinking is that writing to *
Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19015
--
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19032
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-16
11:36 ---
> read *, print_to_file
> if (print_to_file) then
>open(6,file="stdout")
> end if
>
> Is this possible with ifort?
I haven't found anything like that.
The discu
ion: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.or
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-18
19:21 ---
What I meant was that the bug is possibly related to PR 19064.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19071
: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19101
1 - 100 of 332 matches
Mail list logo
