--- Comment #5 from jv244 at cam dot ac dot uk 2008-08-08 20:39 ---
has J3 judged the testcase ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34805
--- Comment #19 from jv244 at cam dot ac dot uk 2008-08-08 20:52 ---
Is this still an ice-on-valid-code ? I can't reproduce that here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34828
--- Comment #9 from jv244 at cam dot ac dot uk 2008-08-08 21:06 ---
what is the 'rejects-valid' testcase here? apart from ifort, all compilers I
can access right now reject the program in the initial comment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35299
--- Comment #3 from jv244 at cam dot ac dot uk 2008-08-08 21:13 ---
works correctly with e.g. ifort and xlf90, so worth fixing somehow.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #2 from jv244 at cam dot ac dot uk 2008-08-08 21:31 ---
This turned in a rejects valid ?
pr35840.f90:1.25:
write(10,*, asynchronous=Y//E//trim(S ))
1
Error: ASYNCHRONOUS= specifier at (1) must be an initialization expression
--
jv244 at cam dot
--- Comment #6 from jv244 at cam dot ac dot uk 2008-08-08 21:38 ---
the testcase in comment #4 is working now. Is the bug still open?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35937
--- Comment #4 from jv244 at cam dot ac dot uk 2008-08-08 21:43 ---
also works without problems on x86_64 (linux)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35952
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known
--- Comment #3 from jv244 at cam dot ac dot uk 2008-08-08 22:15 ---
Maybe a hint from xlf90:
xlf90 test.f90
test.f90, line 3.41: 1516-045 (E) Source is longer than target. Truncation
will occur on the left.
test.f90, line 6.14: 1516-045 (E) Source is longer than target. Truncation
--- Comment #4 from jv244 at cam dot ac dot uk 2008-08-08 22:23 ---
this bug seems fixed in 4.4.0, should it be closed?
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #14 from jv244 at cam dot ac dot uk 2008-08-08 22:27 ---
This appears fixed on current trunk, should the bug be closed.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #6 from jv244 at cam dot ac dot uk 2008-08-08 22:33 ---
I wonder if this bug can be closed, the testcase appears to work with trunk
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-01-01 01:25 ---
*** Bug 34633 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
at cam dot ac dot uk
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37045
--- Comment #1 from jv244 at cam dot ac dot uk 2008-08-07 12:21 ---
Just in case this is useful, this is the corresponding command line:
/data/vondele/gcc_bench/gcc_trunk/obj/./prev-gcc/xgcc
-B/data/vondele/gcc_bench/gcc_trunk/obj/./prev-gcc/
-B/data/vondele/gcc_bench/gcc_trunk/build
--- Comment #9 from jv244 at cam dot ac dot uk 2008-07-25 10:20 ---
Any plans to look into a fix for this for 4.3.X ? This is variant of the
testcase that causes a runtime abort (trunk on x86_64-unknown-linux-gnu):
gfortran -O2 test.f90 ; ./a.out
Operating system error: Cannot
: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36931
: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36932
dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36933
: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36935
--- Comment #2 from jv244 at cam dot ac dot uk 2008-07-25 14:26 ---
(In reply to comment #1)
Reads similar to http://gcc.gnu.org/ml/fortran/2008-07/msg00163.html
PaulT wrote:
pt = point((/ x, y, z /))
1
Warning: Creating array temporary at (1)
This will always
--- Comment #15 from jv244 at cam dot ac dot uk 2008-07-03 13:43 ---
(In reply to comment #13)
Fixed with rev 137386. Btw I have also tried compiling the whole CP2K, which
seems to work fine.
I've also checked that gfortran now appears to compile correctly the procedure
pointer part
--- Comment #8 from jv244 at cam dot ac dot uk 2008-06-30 06:22 ---
(In reply to comment #6)
It looks like you run out of stack space during GC walk. You can check if so
by raising the stack limit with 'ulimit -s unlimited'.
current trunk (actually a few days old) doesn't fail
--- Comment #5 from jv244 at cam dot ac dot uk 2008-05-30 07:40 ---
A few days ago I started a compilation with
[EMAIL PROTECTED]:/data03/vondele/gcc_trunk/CP2K_gcc_2007_06/src gfortran -v
-c --param ggc-min-expand=0 --param ggc-min-heapsize=4096 -O3 -ffast-math
-ftree-vectorize -march
--- Comment #9 from jv244 at cam dot ac dot uk 2008-05-25 12:13 ---
It's not complete yet, and some details need to be fixed, but the basic
functionality is there. I hope it can be committed to trunk quite soon.
that would be great... I really hope this will be enough to enable
--- Comment #5 from jv244 at cam dot ac dot uk 2008-05-20 06:45 ---
this seems one of the few wrong-code bugs that affects Fortran95 in a system
independent way. Any chance to fix this, with a backport to 4.3(.2) ? I believe
we could try to code around it for new versions of CP2K
--- Comment #10 from jv244 at cam dot ac dot uk 2008-05-20 08:09 ---
I've tested the patches posted here for PR36198, and they appear to fix the
problem. Did they pass on the gccfarm?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36206
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36276
--- Comment #1 from jv244 at cam dot ac dot uk 2008-05-20 10:16 ---
Created an attachment (id=15656)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15656action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36276
--- Comment #2 from jv244 at cam dot ac dot uk 2008-05-20 15:28 ---
Created an attachment (id=15657)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15657action=view)
an 8 line testcase
valgrind --tool=memcheck
/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu
--- Comment #5 from jv244 at cam dot ac dot uk 2008-05-19 14:07 ---
with the patches for PR36206, d3_poly appears to compile. However, gfortran
segfaults later in the compilation process.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36198
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 29975
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36265
--- Comment #6 from jv244 at cam dot ac dot uk 2008-05-19 14:22 ---
(In reply to comment #5)
with the patches for PR36206, d3_poly appears to compile. However, gfortran
segfaults later in the compilation process.
this seems an unrelated issue, now PR36265. I would say the patches
--- Comment #2 from jv244 at cam dot ac dot uk 2008-05-19 14:35 ---
(In reply to comment #1)
Yes, I actually have known about that ICE for a few hours now, and have a
patch
ready (I'm now working to reduce a testcase to add with the patch). I actually
sent you a mail to warn you
--- Comment #3 from jv244 at cam dot ac dot uk 2008-05-18 17:52 ---
I think this bug is back. Current gfortran fails again with:
(gdb) run all.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param
l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase
--- Comment #4 from jv244 at cam dot ac dot uk 2008-05-18 17:59 ---
the end of the backtrace (notice the depth) might be useful as well:
#78681 0x00486421 in gt_ggc_mx_lang_tree_node (x_p=value optimized
out) at ./gt-fortran-f95-lang.h:290
#78682 0x00632f85
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 29975
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36198
--- Comment #1 from jv244 at cam dot ac dot uk 2008-05-10 08:44 ---
Created an attachment (id=15624)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15624action=view)
all files needed to reproduce and a README with the command
all files needed to reproduce and a README
--- Comment #14 from jv244 at cam dot ac dot uk 2008-05-10 08:46 ---
(In reply to comment #13)
Fixed for 4.4, patch needs to be backported to 4.3 branch.
thanks for the patch, testing it, I ran into another ICE (PR36198) before
reaching the crucial point.
--
http://gcc.gnu.org
--- Comment #2 from jv244 at cam dot ac dot uk 2008-05-10 10:03 ---
backtrace
#0 internal_error (gmsgid=0xc2d800 tree check: %s, have %s in %s, at %s:%d)
at /data03/vondele/gcc_trunk/gcc/gcc/diagnostic.c:594
#1 0x008a284e in tree_check_failed (node=0x2b6a9f6ec4c0, file
--- Comment #7 from jv244 at cam dot ac dot uk 2008-05-10 12:30 ---
(In reply to comment #6)
With current trunk, I see current mainline gfortran being 5% faster than Intel
10.0 on a Dual-Core AMD Opteron(tm) Processor 2212 at 2GHz. Joost, on your
particular setup, does this still run
--- Comment #8 from jv244 at cam dot ac dot uk 2008-05-10 13:43 ---
(In reply to comment #7)
This is, however, with gfortran 4.3.0.
Trunk is marginally faster than 4.3.0, still about 20% slower than ifort
Kernel time 4.5042820
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
--- Comment #1 from jv244 at cam dot ac dot uk 2008-05-07 08:45 ---
here things appear to work ? What are the numbers you have for '--param
ggc-min-expand=30 --param ggc-min-heapsize=4096' ?
gfortran -c -O2 -g -fmem-report all.f90
Memory still allocated at the end of the compilation
--- Comment #3 from jv244 at cam dot ac dot uk 2008-05-06 09:29 ---
Created an attachment (id=15585)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15585action=view)
files (.f .gcda .mod) needed to reproduce the ICE and a README
attached the files needed to trigger
--- Comment #4 from jv244 at cam dot ac dot uk 2008-05-06 12:08 ---
older gcc versions (tested 4.2.3 and 4.3.0) seem to work fine
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #154 from jv244 at cam dot ac dot uk 2008-05-05 10:31 ---
this PR remains meaningful, but indeed the component should be changed to
'other'
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 29975
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
--- Comment #1 from jv244 at cam dot ac dot uk 2008-05-05 12:29 ---
at least a back trace, but I guess that is not very useful:
#0 internal_error (gmsgid=0xc34369 verify_histograms failed) at
/data03/vondele/gcc_trunk/gcc/gcc/diagnostic.c:594
#1 0x008c949d
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 29975
nThis:
http://gcc.gnu.org
--- Comment #2 from jv244 at cam dot ac dot uk 2008-05-05 13:11 ---
also happens if profiles are generated/used at -O2 instead of -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 29975
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36132
--- Comment #1 from jv244 at cam dot ac dot uk 2008-05-05 13:25 ---
testcase:
MODULE M1
INTEGER, PARAMETER :: dp=KIND(0.0D0)
CONTAINS
SUBROUTINE S1(a)
REAL(dp), DIMENSION(45), INTENT(OUT),
OPTIONAL :: a
IF (PRESENT(a)) a=0.0_dp
--- Comment #3 from jv244 at cam dot ac dot uk 2008-05-05 15:28 ---
right, it is actually new CP2K code since I checked 4.3. No regression thus.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 29975
nThis:
http
--- Comment #151 from jv244 at cam dot ac dot uk 2008-05-03 18:17 ---
New ICE PR36119, reopening.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #3 from jv244 at cam dot ac dot uk 2008-05-02 14:35 ---
confirmed on x86_64-unknown-linux-gnu
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36071
--- Comment #149 from jv244 at cam dot ac dot uk 2008-04-28 12:45 ---
new ICE, PR36071.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status
--- Comment #1 from jv244 at cam dot ac dot uk 2008-04-28 12:48 ---
trace
rogram received signal SIGSEGV, Segmentation fault.
0x005b4e18 in operand_equal_p (arg0=0x2b9220d76420,
arg1=0x2b9220c5b240, flags=0) at
/data03/vondele/gcc_trunk/gcc/gcc/fold-const.c:3037
3037
--- Comment #2 from jv244 at cam dot ac dot uk 2008-04-28 12:55 ---
revision 134754 seems to pass.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36071
--- Comment #3 from jv244 at cam dot ac dot uk 2008-04-28 13:56 ---
assuming fixed
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status
: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35881
--- Comment #1 from jv244 at cam dot ac dot uk 2008-04-09 08:07 ---
reading a bit more, this seems a real bug.
Can this be fixed for 4.3, pretty please ?
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #2 from jv244 at cam dot ac dot uk 2008-04-09 10:58 ---
also confirmed for trunk
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Known
--- Comment #3 from jv244 at cam dot ac dot uk 2008-04-09 13:31 ---
I decided to ask, and maybe it is correct anyway, even though I have not fully
followed the bit on 'nthreads-var'
http://www.openmp.org/forum/viewtopic.php?f=3t=100
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #148 from jv244 at cam dot ac dot uk 2008-02-18 08:10 ---
(In reply to comment #147)
(In reply to comment #146)
(In reply to comment #145)
current gfortran trunk seems to fail on CVS sources of CP2K with:
PR34946
Joost - can this be closed again?
Done, but I hope
--- Comment #6 from jv244 at cam dot ac dot uk 2008-02-11 11:25 ---
(In reply to comment #5)
Or are you complaining that we constant fold integer powers as if they were
non-integer powers
Richard,
I think I'm suggesting more a enhancement than a bug fix. Some good quality
compiler
--- Comment #15 from jv244 at cam dot ac dot uk 2008-01-29 06:31 ---
the comment #10 test case is still broken, and reaching its 3rd anniversary
soon. Just a back trace to the segfault:
1347 cons = cons-next;
(gdb) bt
#0 0x00422cda in find_array_section (expr
--- Comment #15 from jv244 at cam dot ac dot uk 2008-01-25 19:10 ---
(In reply to comment #12)
For another ICE at trans-array.c:592 see example at PR31610, comment #12.
yes, it is almost certainly the same problem:
integer :: i(1) = 0
write(*,*) foo(i+[1])
end
compiles while
--- Comment #4 from jv244 at cam dot ac dot uk 2008-01-24 08:08 ---
and also confirmed for the latest gfortran:
gcc version 4.3.0 20080124 (experimental) [trunk revision 131776]
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34946
--- Comment #7 from jv244 at cam dot ac dot uk 2008-01-24 15:22 ---
(In reply to comment #6)
When did this last work?
unfortunately I don't know. This piece of code might actually be newer than my
latest test of gfortran on CVS CP2K.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #11 from jv244 at cam dot ac dot uk 2008-01-24 16:05 ---
What is the date on the 4.2.2?
the relevant data might be the branching of 4.2
+-- GCC 4.2 branch created --+
|(Oct 20 2006)\
v v
org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
--- Comment #4 from jv244 at cam dot ac dot uk 2008-01-23 15:45 ---
(In reply to comment #2)
It's considered too big and it's not static.
not sure if my C is good enough to reply, but CS1 is visible only from within
the subroutine S1. That's somewhat similar to (or stricter than
--- Comment #5 from jv244 at cam dot ac dot uk 2008-01-23 17:22 ---
just a note, ifort does inline the function cs1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
--- Comment #145 from jv244 at cam dot ac dot uk 2008-01-23 19:02 ---
current gfortran trunk seems to fail on CVS sources of CP2K with:
/data03/vondele/clean/cp2k/src/../src/realspace_grid_types.F: In function
rs_grid_create:
/data03/vondele/clean/cp2k/src/../src
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34946
--- Comment #1 from jv244 at cam dot ac dot uk 2008-01-23 19:25 ---
Created an attachment (id=15010)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15010action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34946
--- Comment #146 from jv244 at cam dot ac dot uk 2008-01-23 19:30 ---
(In reply to comment #145)
current gfortran trunk seems to fail on CVS sources of CP2K with:
PR34946
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
--- Comment #3 from jv244 at cam dot ac dot uk 2008-01-24 07:27 ---
reduced testcase:
MODULE test
TYPE realspace_grid_input_type
INTEGER :: distribution_layout(3)
END TYPE realspace_grid_input_type
TYPE realspace_grid_type
INTEGER, DIMENSION (3) :: npts
--- Comment #5 from jv244 at cam dot ac dot uk 2008-01-17 06:12 ---
with allocatable structure components, this likely is not a 'f95 only' bug
(PR32834).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34820
--- Comment #5 from jv244 at cam dot ac dot uk 2008-01-08 09:52 ---
updated the summary after the analysis in comment #4, and and CCed Dorit for
the vectorization issue.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #4 from jv244 at cam dot ac dot uk 2008-01-07 22:00 ---
timings have improved a lot with a recent gfortran, at least on an opteron, I
have now for ifort 3.7s for gfortran 4.5s (20% slower only) for the following
code:
SUBROUTINE collocate_core_2_2_0_0(jg,cmax)
IMPLICIT
--
Summary: no unformatted on internal file
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34655
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34657
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34659
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34660
/ ASSIGNMENT(=)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34662
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34663
: function ref not allowed
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34665
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34656
--- Comment #2 from jv244 at cam dot ac dot uk 2008-01-04 07:02 ---
(In reply to comment #1)
This is almost impossible to diagnose. Do you know of any compiler that
detects this?
I think that lahey detects this at runtime. Almost all compilers detect the
simple case of directly (i.e
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from jv244 at cam dot ac dot uk 2007-12-21 06:09 ---
code compiles fine with NAG and g95, the line at the segfault looks OK.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
601 - 700 of 1178 matches
Mail list logo
