--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-06
17:01 ---
(In reply to comment #5)
I'm no Fortran guru, but could be this related to PR 17675?
I don't think this is an alignment problem. Apparently,
ia64-unknown-linux-gnu sets up the processor differently
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-06
17:28 ---
I don't think PR 18476 needs to be in there. The test case is
invalid (just putting nml instead of nml= into the list).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-05
08:33 ---
A testcase with character variables:
$ gfortran cline
$ cat cline.f
character*2 c1,c2
open(7)
write (7,'(A1)') 'a','b','c'
rewind(7)
read(7,'(A2)') c1,c2
print *,c1
Severity: minor
Priority: P3
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=19259
Severity: minor
Priority: P3
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=19260
Version: 4.0.0
Status: UNCONFIRMED
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
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-05
11:18 ---
The following is also illegal:
$ cat continuation-4.f90
! This is a comment
end
$ gfortran continuation-4.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19261
: minor
Priority: P3
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=19262
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-05
11:39 ---
I've found that gcc -dumpmachine does what I want.
Still, it would be nice to have that information included in -v.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19117
.
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
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
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
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-04
09:30 ---
Here are results on ia64-unknown-gnu-linux, with -O0 -g for
gfortran snapshot 20050102.
What I don't understand is that the results appear identical
to the ones that I showed in comment 8 with snapshot
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-04
13:41 ---
The problem appears to be related to the fact that length
and size are both intrinsics.
If you declare length to be external, with the following
patch:
$ diff -u vec3d.f90 vec3d-works.f90
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-04
14:54 ---
I did some debugging on my testcase, and I think I've found
some of the things wrong with it:
$ gdb ./a.out
GNU gdb Red Hat Linux (6.1post-1.20040607.52rh)
Copyright 2004 Free Software Foundation, Inc
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-04
22:20 ---
Even shorter testcase:
$ cat fio.f
open(7)
write (7,'(F12.5)') 1.0, 2.0, 3.0
rewind(7)
read(7,'(F15.5)') a,b
print *,a,b
if (abs(a-1.0) .gt. 1e-5) call abort
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-04
22:31 ---
$ gfortran fio.f ./a.out
1.00 3.00
$ gfortran -dumpmachine
i686-pc-linux-gnu
Aborted
I had mixed up my cutpaste there... of course,
it was the test program that aborted
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-01
22:07 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00024.html
--
What|Removed |Added
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-27
10:26 ---
(In reply to comment #6)
Can you try just -funsafe-math-optimizations and see what happens I think you
will get the same
results as -ffast-math -fno-finite-math-only as I think an instruction
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-27
22:24 ---
I did some more digging around, and found that
the error only occurred when the mask parameter
was generated on the fly. If the mask is a
precomputed logical array, the function works
correctly.
$ cat
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-25
09:31 ---
(In reply to comment #1)
The latest version of the F95 draft standard (isn't the world
of coypyrighted standards wonderful?) states
# If a character context is to be continued, the shall
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-25
09:34 ---
(In reply to comment #3)
maybe fixed by pr19071, please check !!
Yes, it is fixed.
$ ./a.out
( 2.00 , 0.00 ) ( 0.25250582600 ,
0.00
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-25
14:32 ---
I find strange that the C equivalent does not
compare an NaN equal to itself, even with
-O3 -ffast-math :
$ cat nan-check.c
#include stdio.h
#include math.h
int equality(double a, double b);
int main
not treated as zeros in 'E' format read
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
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-25
22:17 ---
It is actually possible to reproduce the
Fortran behavior in C:
$ cat nan-check2.c
#include stdio.h
#include math.h
int equality(double *a, double *b);
int main()
{
double a, b, c;
a = 0.0
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-22
16:52 ---
The issues with PACK are fixed, keeping this open as a reminder that UNPACK
still has issues as pointed out in #4
Test case for the scalar case:
$ cat unpack.f90
program main
real, dimension(3
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-22
16:55 ---
The problem seems to occur with other array
intrinsics, too.
On i686-pc-linux-gnu :
$ cat unpack2.f90
program main
real, dimension(3) :: a, b
logical, dimension(3) :: l
l = (/ .false., .true
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
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
-ffast-math
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-21
21:02 ---
(In reply to comment #1)
Hmm, this works for me on the mainline on powerpc-darwin. What target is
this?
I was used to gfortran -v telling me that... i686-pc-linux-gnu.
--
http://gcc.gnu.org
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=19117
Severity: enhancement
Priority: P2
Component: web
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=19118
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
--- 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
--
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
formula a - floor(a/b
--- 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
: 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
--
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 discussion on comp.lang.fortran showed that
F
.
--
Summary: print *,maxloc(array) segfaults
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig
: 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=19016
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
--- 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 * (or PRINTing)
should
Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19015
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-14
16:07 ---
Lapack on the IA-64 does not look good right now.
Here are the results with 20041212 snapshot, with Steve Kargl's I/O
patch from http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00844.html
applied:
CES
: 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
GCC host triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
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-13
08:57 ---
It's not exponential, the exponent is somewhere between
2.2 and 2.3.
Here's a number of test cases on an Itanium 2 with 1.3 GHz:
$lasttime(s)
1 476.4
7000212.8
5000101.2
300029.8
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-13
13:51 ---
I just reran the PR 12366 testcase and found that this
is indeed a duplication. *sigh*
*** This bug has been marked as a duplicate of 12366 ***
--
What|Removed
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-13
13:52 ---
*** Bug 18955 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-14
11:08 ---
Same problem with -O1 . -O0 doesn't segfault.
--
What|Removed |Added
Summary
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-14
13:30 ---
I forget...
$ gfortran -v
Reading specs from /home/zfkts/lib/gcc/ia64-unknown-linux-gnu/4.0.0/specs
Configured with: ../gcc-4.0-20041212/configure --prefix=/home/zfkts
--enable-languages=c,c++,f95
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=18983
: 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=18985
: 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
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
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
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
: 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
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-12
16:19 ---
g77 has the same problem:
$ time g77 spaghetti.f
real0m11.649s
user0m11.516s
sys 0m0.068s
$ ./spaghetti 2 spaghetti.f
$ time g77 spaghetti.f
real0m50.604s
user0m48.738s
sys
--- 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-case-c 15
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
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-11
10:40 ---
(In reply to comment #1)
Actually all of the time is spent in the parser so this is not a middle-end
problem.
You're correct. For example, the C frontend does not exhibit
this behavior:
$ ./spaghetti
: 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=18938
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc
--
What|Removed |Added
Severity|normal |enhancement
Status|WAITING |NEW
Ever Confirmed|
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
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=18883
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-08
16:24 ---
(In reply to comment #1)
Is this a language extension? Seems likely, as the standard has no concept of
stdin and stdout. Could you point to someplace where this extension is
specified?
It's
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=18869
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=18870
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=18872
: 3.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libf2c
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
: 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=18879
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-06
08:37 ---
(In reply to comment #1)
Alternatively, do other compilers omit padding in sequence types?
ifort does so, unless the '-pad' option is given:
http://www.intel.com/software/products/compilers/flin/docs
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=18850
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-05
20:03 ---
*** Bug 18834 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-05
20:03 ---
(In reply to comment #2)
Confirmed. This might be a dup of bug 15966 or PR 18781.
Yes, I think this is a dupe of PR 15966. PR 18781 is a bit different,
because there, it is the format which
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-04
10:37 ---
This does indeed appear to be the problem
with quite a few failing NIST tests. Here's
a reduced testcase from NIST 111. The test case
in question has the comment
C*- USE AS A FORMAT
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=18824
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
Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18827
--
What|Removed |Added
Summary|compiler segfault on assign |ICE on assign to common
|to common variable |variable
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-04
14:56 ---
The same bug is triggered if the assigned variable
is equivalenced:
$ cat assign4.f
program main
integer i
integer j
equivalence (i,j)
assign 1000 to i
goto j
1000
spec' on integer/char equivalence
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
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
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-04
21:18 ---
It's also the same bug that lets NIST 909 fail.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18834
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=18794
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-30
08:29 ---
(In reply to comment #3)
This is a target problem, most likely what is happening is that the memory
where the variable is being
stored is not being marked as read only for the processor
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-25
20:29 ---
(In reply to comment #1)
No it is just undefined on most targets we do seg fault.
I realize that this is undefined, but it would still be nice
to get consistent behavior (i.e. a consistent segfault
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-22
12:29 ---
(In reply to comment #5)
Hmmm, I do not get this on my powerpc-unknown-linux-gnu:
I am also not getting this with -O on ia64-unknown-linux-gnu . Apparently,
the array assignment in bar is commented
201 - 300 of 326 matches
Mail list logo
