--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26
09:32 ---
The recent fixes in complex handling, and the
scaled division algorithm, have eliminated the
Lapack regressions with -O0 at least on ia64-unknown-linux-gnu
(see http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26
09:42 ---
At -O1 on ia64-unknown-linux-gnu, I still run into PR 18977
(segfault in xeigtsts). Pity.
--
What|Removed |Added
--
What|Removed |Added
OtherBugsDependingO||5900
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26
15:26 ---
(In reply to comment #8)
> Is there a test case someone can attach to this bug?
I'm working on it. The error vanishes if slasy2.f is
compiled with -O0, which is at least a start.
An equivale
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26
17:23 ---
Here we go:
$ cat sl-error.f
implicit none
real x(2,2)
call foo(x)
end
subroutine foo(x)
real x(2,2)
real tmp(4), t16(4,4), btmp(4),temp
DO 120 I = 1, 4
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26
19:46 ---
Selected component "target" instead of "fortran".
--
What|Removed
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://
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-26
21:43 ---
There are two parts to this bug. The other is that eor is
that end-of-line processing is broken. Here's a test case
with the patch from comment #2 applied:
$ cat eor_2.f90
program main
charac
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-27
15:09 ---
Created an attachment (id=8084)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8084&action=view)
Failing C source code
This is indeed a target bug. I've attached a C source
code (
--
What|Removed |Added
Summary|LAPACK test xeigtsts|[4.0 regression] LAPACK test
|segfaults with optimization |xeigtsts segfaults with
--
What|Removed |Added
Known to fail||4.0.0
Known to work||3.2.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-27
19:52 ---
(In reply to comment #3)
> In this
> case, transformation could be enhanced to combine multiple divisions, as it is
> explained in Agner Fog's "How to optimize for th
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=19668
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-28
11:14 ---
This bug is shared by both g77 3.2.3 and ifort 8.1.
Good company, at least :-)
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19668
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-28
13:47 ---
Created an attachment (id=8090)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8090&action=view)
Simpler example of failing C source code
This is a simpler example of failing C code (whic
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-28
14:29 ---
The inner loop does not terminate in this example,
until a segfault is hit.
$ cat sl5-error.c
#include
void foo(float * x);
int main()
{
float x[4];
foo (x);
return 0;
}
void foo (float *x
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-28
22:47 ---
Ouch, I should read my test programs before I post bug reports.
Resolving as invalid.
Thomas
--
What|Removed |Added
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=19678
ork for formatted input if line length
is exceeded
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas d
rget
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 target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19690
--
What|Removed |Added
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19690
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-29
20:01 ---
Created an attachment (id=8103)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8103&action=view)
Failing preprocessed C source code
To see wether this problem can also be exposed wit
Priority: P2
Component: target
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 target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19700
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-29
21:11 ---
Created an attachment (id=8104)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8104&action=view)
Failing source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19700
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-31
14:38 ---
This is with the 20050130 snapshot on ia64-unknown-linux-gnu,
-O3 and with flag_complex_divide_method = 1. The files slasy2.f
and dlasy2.f are compiled with -O0, to get around PR 18977.
cgd.out: CGV
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-31
17:02 ---
This looks promising.
I'll do a full check later.
Thomas
--- transfer.c.orig 2005-01-31 18:03:12.0 +0100
+++ transfer.c 2005-01-31 18:04:00.0 +0100
@@ -150,6 +1
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-01
13:08 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02295.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19568
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-01
16:41 ---
The patch does not handle advance="NO" correctly.
I'll need to do something else.
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19568
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-01
20:01 ---
Replying to myself here...
After having thought of this, I think the patch should go in
because it fixes a g77 regression, and advance= isn't among the
things that g77 supports.
Thomas
--
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-02
21:07 ---
The patch for the first part of the bug is applied,
the second part is still open. Removed patch keyword
accordingly.
--
What|Removed |Added
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-07
08:48 ---
g77 can do this:
$ cat dosfile.f
write(10,'(2A)') '1',achar(13)
rewind(10)
read (10,*) n
print *,n
end
$ g77 dosfile.f
$ ./a.out
1
$ g77 -v
Reading
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-07
14:03 ---
Things are strange on IA-64.
I played around a bit with different optimization levels
for xeigtstd with ded.in as input file. I compiled everything
at -O1 and -O3, and then tried replacing single
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08
09:24 ---
On ia64-unknown-linux-gnu, -O1 produces the same result that -O3 does.
Here's a shell script that I currently use for shotgun
testing of single optimization options:
for a in \
branch-count-reg
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08
15:36 ---
(In reply to comment #34)
> Please, try the opposite: disable optimizations through -O1 -fno-[optnam] and
> see if you find out something.
Still the same four failures with
#! /bin/sh
fo
k
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-bugs at
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08
16:36 ---
This blocks testing of compiler options in PR 5900.
--
What|Removed |Added
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08
16:36 ---
I am not sure which of my tests of compiler options
were actually testing anything. There appears to be a bug
in passing at least one -fno - switch (see PR 19825).
Thomas
--
http://gcc.gnu.org
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-09
08:12 ---
gfortran -c -O1 -fno-tree-ccp -fno-tree-ch -fno-tree-copyrename -fno-tree-dce
-fno-tree-dominator-opts -fverbose-asm -fno-unswitch-loops -fno-peel-loops
-fno-unroll-loops -fno-tree-dse -fno-tree-fre
Component: driver
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=19848
--
What|Removed |Added
OtherBugsDependingO||5900
nThis||
Version|unknown |4.0.0
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-09
12:43 ---
See PR 19848.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-09
21:19 ---
Same thing on i686-pc-linux-gnu with the gcc driver:
$ cat main.c
int main()
{
return 0;
}
$ gcc -S -fverbose-asm -o main-o0.s main.c
$ gcc -S -fno-cprop-registers -fno-defer-pop -fno-guess
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10
08:52 ---
(In reply to comment #2)
> There are a gazillion places where we just check "if (optimize)" without
> any specific flag. It would be quite a lot of work to introduce flags for all
> o
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10
10:17 ---
It appears the problem is caused by one of the
optimization options that cannot be controlled with
flags.
One suspect is this code snippet from gcc/config/ia64.c :
static bool
ia64_rtx_costs (rtx x
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10
20:31 ---
*** This bug has been marked as a duplicate of 19848 ***
--
What|Removed |Added
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10
20:31 ---
*** Bug 19825 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
--
Bug 5900 depends on bug 19825, which changed state.
Bug 19825 Summary: -fno-loop-optimize2 does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19825
What|Old Value |New Value
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10
20:35 ---
(In reply to comment #4)
> $ find . -name '*.c' | xargs grep '[(&|!] *optimize[) =!><|&]' | wc -l
> 204
Any idea how I should go about further debugging P
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-11
12:09 ---
(In reply to comment #39)
> One suspect is this code snippet from gcc/config/ia64.c :
>
> static bool
> ia64_rtx_costs (rtx x, int code, int outer_code, int *total)
> case DIV:
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-11
12:10 ---
(In reply to comment #40)
> ** On entry to DGEEV parameter number 1 had an illegal value
I had that one, as well. There are some routines which occur more than
once. Copying the files from
Status: UNCONFIRMED
Severity: enhancement
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
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-13
14:24 ---
No derived type is necessary:
$ cat pr19928.f90
subroutine pr19928
character :: signal_names(10)*16
signal_names = ''
write (*,*) signal_names(:)(1:4)
end subroutine pr19928
$ gfortran p
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-13
17:50 ---
Looking at PR 17123 a bit more closely, I think that
this is a duplicate.
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19928
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-14
12:25 ---
I can confirm that this is fixed in the 20050213 snapshot.
Both the reduced C test case and the original Fortran routine
don't segfault any more. Thanks to whoever fixed this :-)
I would su
c
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: 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
--
What|Removed |Added
OtherBugsDependingO||18902
nThis||
Keywords||missed-
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-14
20:06 ---
Same thing for complex division, where the performance
penalty is probably also pretty severe:
$ cat c-div.c
#include
#include
int main()
{
float a;
complex float b,c;
foo(&a,&b
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-14
22:38 ---
For addition, this is a regression against 3.3.5:
$ cat c-add.c
#include
#include
int main()
{
float a;
complex float b,c;
foo(&a,&b);
c = b+a;
return creal(c) + cima
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-15
10:29 ---
> And in fact this only can happen with -funsafe-math-optimizations (or maybe
with -fno-trapping-
> math because a+0.0 can trap.
Hmm...
if b is complex and has the value (0., signalling NaN) an
Status: UNCONFIRMED
Severity: normal
Priority: 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
GCC target triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
--
What|Removed |Added
OtherBugsDependingO||5900
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
--
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-15
20:14 ---
This does not happen on an Athlon-xp with -march=athlon-xp
-mfmath=sse. Might be target or 64-bit specific.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
: 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=18122
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=18209
ot 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=18210
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
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18290
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-05 21:01
---
(In reply to comment #1)
> Really nobody builds inside the source directory.
How does one actually build the compiler, then? gcc/doc/install.texi simply says
# @section Building a native compi
: 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: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18315
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
nu 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=18392
2
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=18396
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=18476
edBy: 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=18481
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=18518
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-16
10:35 ---
Created an attachment (id=7553)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7553&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18518
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-17
09:18 ---
(In reply to comment #3)
I checked this with gcc-4.0-20041107 on a ia64, and the problem didn't occur:
$ gfortran -v
Reading specs from /home/zfkts/lib/gcc/ia64-unknown-linux-gnu/4.0.0/
cc
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
GCC host
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-17
12:45 ---
Created an attachment (id=7561)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7561&action=view)
log file from testsuite
There appears to be some problem with
loading the shared
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-17
15:39 ---
The code is perfectly valid. Here,
n in the subroutine hides the host parameter n
(which is then inaccessible in the subroutine xx).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18525
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-18
09:02 ---
(In reply to comment #2)
> On AMD x32 the correct result is obtained with g77. g95 and pgfortran work as
> expected, only gfortran stops:
>
> > gfortran d1mach.f && ./a.out
>
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-18
18:53 ---
It appears that equivalenced variables are not
saved.
Here's a simplified test case:
$ cat pr18518-test.f90
program main
call foo
call bar
call foo
end program main
subroutine foo
intege
erity: enhancement
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=18566
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-20
13:19 ---
> Hmmm, I do not get this on my powerpc-unknown-linux-gnu:
Here's a reduced assembly output:
$ gfortran -v
Reading specs from /home/ig25/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
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
rsion: 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.gn
: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P1
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
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-21
10:08 ---
(In reply to comment #1)
> What is the difference between f and the standardized versions of fortran?
F is a subset of Fortran 95.
A list of features not in F95 is at http://www.fortran.co
--- 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 commen
c
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 do
--- 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 segfa
--- 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.
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=18794
--- 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 FORM
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=18824
Summary: compiler segfault on assign to array
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
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=18827
--
What|Removed |Added
Summary|compiler segfault on assign |ICE on assign to common
|to common variable |variable
http://gcc.gnu.org/bugzilla/
--- 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
27;missing 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 Koeni
201 - 300 of 332 matches
Mail list logo
