The problem with
2.0**-3*5
is whether it should be interpreted as 2.0**(-3) * 5 or as 2.0**(-3*5).
gfortran does the former, ifort the latter.
g95, openf95, sunf95 and (of cause) NAG f95 reject it always.
ifort: Accepts it, unless -stand f* is used.
gfortran: Warning for -pedantic, Error for
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-20 08:04 ---
See also:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/30039cbb71280a3b/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34536
--- Comment #12 from burnus at gcc dot gnu dot org 2007-12-20 08:13 ---
Subject: Bug 34482
Author: burnus
Date: Thu Dec 20 08:13:09 2007
New Revision: 131098
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131098
Log:
2007-12-20 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #13 from burnus at gcc dot gnu dot org 2007-12-20 08:15 ---
FIXED on the trunk (4.3.0) [does not affect 4.2.x or 4.1.x].
Thanks for the report.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-12-20 08:17 ---
Subject: Bug 34530
Author: burnus
Date: Thu Dec 20 08:16:48 2007
New Revision: 131099
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131099
Log:
2007-12-20 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #4 from burnus at gcc dot gnu dot org 2007-12-20 08:22 ---
FIXED on the trunk (4.3.0).
Thanks for the report.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5a1e0cc2c7eb95cc/
character, pointer :: ptr(:)
allocate(ptr(8))
ptr = transfer('Sample'//achar(0),ptr) ! Causes ICE
end
gives a Floating Point Exception.
--
Summary: ICE (FPE) for
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-20 08:42 ---
gdb shows:
Program received signal SIGFPE, Arithmetic exception.
0x0046b86e in gfc_simplify_transfer (source=0x26a7b30, mold=0x1,
size=0x0)
at /projects/tob/gcc/gcc/fortran/simplify.c:4138
4138
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #1 from olga at gcc dot gnu dot org 2007-12-20 09:32 ---
Would you please provide me with the following:
-dump files for all failures (as you did for PR34472)
-configuration options you use
-at least initial debugging (where it fails)
Thank you,
Olga
--
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-20 10:30 ---
Posted 2 alternative patches:
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00983.html
http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00985.html
(though IMHO both are desirable).
--
jakub at gcc dot gnu dot org
--- Comment #2 from burnus at gcc dot gnu dot org 2007-12-20 10:57 ---
at /projects/tob/gcc/gcc/fortran/simplify.c:4138
4138 result_length = source_size / result_elt_size;
Here, source_size is correctly 8, but result_elt_size == 0 instead of 1
(character(len=1)).
The
--- Comment #2 from charlet at gcc dot gnu dot org 2007-12-20 11:26 ---
Actually, we do not claim annex d conformance in GCC, so closing this PR,
since on linux (which is what this report is referring to), it does not make
sense to go to the hardware level.
Arno
--
charlet at gcc
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-12-20 11:56
---
Note I also saw this on powerpc-linux-gnu but I have not checked after the
patch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-12-20 12:40 ---
See F95, Section 7.4 Precedence of operators, Table 7.8
Exponentation has a higher precedence than multiplication, so
2.0**-3*5 = (2.0**(-3)) * 5
Hence, is a warning really necessary?
--
dfranke at gcc dot
--- Comment #27 from bonzini at gnu dot org 2007-12-20 13:53 ---
I screwed up so I have to rerun most of SPECfp2000, but the results seem a
wash. Anybody can fire the patch I'll attach soon on a wide range of machines?
--
Bug 17236 depends on bug 6585, which changed state.
Bug 6585
--- Comment #3 from burnus at gcc dot gnu dot org 2007-12-20 14:04 ---
Exponentation has a higher precedence than multiplication, so
2.0**-3*5 = (2.0**(-3)) * 5
You forgot about the minus sign. You have:
[constant][exponent][minus][constant][times][constant]
and not
--- Comment #28 from bonzini at gnu dot org 2007-12-20 14:15 ---
Created an attachment (id=14800)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14800action=view)
combined patch
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #4 from dfranke at gcc dot gnu dot org 2007-12-20 14:23 ---
You forgot about the minus sign.
Blind spot. If in doubt, I have a habit of putting extra-paranthesis anyway :)
On topic:
Metcalf, Section 3.2, states: [...] a unary minus or plus must not follow
immediately
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-12-20 14:32 ---
http://gcc.gnu.org/onlinedocs/gfortran/DTIME.html
Description:
Subsequent invocations of DTIME return values accumulated since the previous
invocation.
Return value:
Elapsed time in seconds since the start of
--- Comment #2 from niemayer at isg dot de 2007-12-20 14:32 ---
I can second that problem for template member functions - in contrast to
non-template member functions, where the attribute works.
This gives a warning about deprecation as expected:
--- Comment #7 from jakub at gcc dot gnu dot org 2007-12-20 14:40 ---
Subject: Bug 34459
Author: jakub
Date: Thu Dec 20 14:40:33 2007
New Revision: 131101
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131101
Log:
PR c++/34459
* tree-ssa-dse.c (dse_optimize_stmt):
--- Comment #8 from jakub at gcc dot gnu dot org 2007-12-20 14:43 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #43 from zadeck at naturalbridge dot com 2007-12-20 14:49
---
Subject: Re: Inordinate compile times on large
routines
lucier at math dot purdue dot edu wrote:
--- Comment #42 from lucier at math dot purdue dot edu 2007-12-20 03:52
---
Created an attachment
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-20
14:45 ---
Subject: Re: [4.3 Regression] ICE in extract_insn, at recog.c:1990 on hppa
Thanks for fixing this so quickly.
Actually, I realized last night that I failed to load the function label
from memory. I'll
--- Comment #45 from zadeck at naturalbridge dot com 2007-12-20 15:31
---
Subject: Re: Inordinate compile times on large
routines
stevenb dot gcc at gmail dot com wrote:
--- Comment #44 from stevenb dot gcc at gmail dot com 2007-12-20 15:08
---
Subject: Re: Inordinate
--- Comment #44 from stevenb dot gcc at gmail dot com 2007-12-20 15:08
---
Subject: Re: Inordinate compile times on large routines
On 20 Dec 2007 14:49:12 -, zadeck at naturalbridge dot com
[EMAIL PROTECTED] wrote:
--- Comment #43 from zadeck at naturalbridge dot com
--- Comment #2 from dominiq at lps dot ens dot fr 2007-12-20 15:57 ---
Description:
Subsequent invocations of DTIME return values accumulated since the previous
invocation.
Return value:
Elapsed time in seconds since the start of program execution.
This at best ambiguous and,
--- Comment #46 from zadeck at naturalbridge dot com 2007-12-20 16:06
---
Subject: Re: Inordinate compile times on large
routines
indexes will be 0, 1, 2, 3.
there are no def-def chains, and in particular there are no artificial
def to artificial def chains. those increments
--- Comment #47 from lucier at math dot purdue dot edu 2007-12-20 16:11
---
Subject: Re: Inordinate compile times on large routines
I don't know what's happening here, the patch doesn't apply; first I get
euler-13% patch zadeck2.patch
patching file df-problems.c
patch:
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-12-20 16:41 ---
Another question: contrary to g77, we now have support for OpenMP. How about
concurrency issues? Shall DTIME give the time since the last invokation from
any thread, i.e. maintain a global storage, or the last
#include sstream
#include stdexcept
int func()
{
std::string s;
throw std::invalid_argument( s );
}
g++-4.3.0 -std=c++0x test.cpp
test.cpp: In function 'int func()':
test.cpp:7: error: 'invalid_argument' cannot be used as a function
this code compiles only, if -std=c++0x is not
--- Comment #48 from zadeck at naturalbridge dot com 2007-12-20 17:28
---
Created an attachment (id=14801)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14801action=view)
patch to count different types of def-use chains
this patch replaces the one munged by bugzilla
--
Between revision 130941 and revision 131009, there are extra libmudflap
failures:
+FAIL: libmudflap.c++/fail24-frag.cxx (-O2) (test for excess errors)
+FAIL: libmudflap.c++/fail24-frag.cxx (-O3) (test for excess errors)
+FAIL: libmudflap.c++/fail24-frag.cxx ( -O) (test for excess errors)
+FAIL:
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-20 17:35 ---
*** This bug has been marked as a duplicate of 34535 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-12-20 17:35 ---
*** Bug 34539 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2007-12-20 17:39 ---
This is already fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #1 from pcarlini at suse dot de 2007-12-20 17:44 ---
This is a known issue:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#697
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #2 from hjl at lucon dot org 2007-12-20 17:45 ---
Created an attachment (id=14802)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14802action=view)
Dump files
Starting program:
/export/build/gnu/gcc/build-ia64-linux/gcc/testsuite/gcc/a.out
Program received signal
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-20 18:05 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-20 18:05 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-20 18:07 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-20 18:07 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34525
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34530
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from kargl at gcc dot gnu dot org 2007-12-20 18:26 ---
(In reply to comment #3)
Another question: contrary to g77, we now have support for OpenMP. How about
concurrency issues? Shall DTIME give the time since the last invokation from
any thread, i.e. maintain a global
--- Comment #2 from rbuergel at web dot de 2007-12-20 18:30 ---
(In reply to comment #1)
This is a known issue:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#697
Ooops. I only looked in the gcc bug database. Probably i should expand my
research before filing a bug
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-12-20 18:35 ---
I think gfortran will need to handle it similar to how random_seed is done.
Using a mutex, yes, that's what I thought as well. Btw, CPU_TIME gives values
per process and does not bother with threads. DTIME
--- Comment #49 from lucier at math dot purdue dot edu 2007-12-20 18:56
---
Subject: Re: Inordinate compile times on large routines
I think this is the extra information you wanted:
real - real = 163962912
real - art = 0
art - real = 0
art - art = 0
Brad
--
--- Comment #6 from kargl at gcc dot gnu dot org 2007-12-20 19:39 ---
(In reply to comment #5)
I think gfortran will need to handle it similar to how random_seed is done.
Using a mutex, yes, that's what I thought as well. Btw, CPU_TIME gives values
per process and does not bother
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-20 19:39 ---
Yeah, works for me on the trunk too.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jakub at gcc dot gnu dot org 2007-12-20 20:01 ---
*** Bug 34467 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34448
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-20 20:01 ---
This is a dup of PR34448, Aldy's latest patch fixes it as well.
*** This bug has been marked as a duplicate of 34448 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from jarygrove at yahoo dot com 2007-12-20 20:32 ---
Subject: Re: SSLEngine - Clone not supported (Null pointer) exception
I tried and got the following output
[Ljava.lang.String;@1f6af68
[Ljava.lang.String;@1f6af60
- Original Message
From: csm at gnu dot
I really thought we had these figured out...
$ cat shift-variations.f90
program main
integer(kind=1) :: d1
integer(kind=2) :: d2
integer(kind=4) :: d4
integer(kind=8) :: d8
integer(kind=1), dimension(2) :: s1
integer(kind=2), dimension(2) :: s2
integer(kind=4), dimension(2) :: s4
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot
|dot org
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot
|dot org
--- Comment #7 from kargl at gcc dot gnu dot org 2007-12-20 21:28 ---
A quick scan of intrinsics.c shows that dtime() is treated as an alias
to etime(). So, one needs to make dtime() a full-fledged intrinsic
procedure.
add_sym_1 (etime, GFC_ISYM_ETIME, NO_CLASS, ACTUAL_NO, BT_REAL,
--- Comment #8 from dfranke at gcc dot gnu dot org 2007-12-20 21:39 ---
one needs to make dtime() a full-fledged intrinsic procedure.
This minute, I just realized the same ...
Daniel, are you working on this PR?
Sort of. Finished the library part.
Btw, CPU_TIME has a fallback
--- Comment #5 from jason at gcc dot gnu dot org 2007-12-20 22:16 ---
Subject: Bug 34111
Author: jason
Date: Thu Dec 20 22:16:19 2007
New Revision: 131107
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131107
Log:
PR c++/34111
* call.c (standard_conversion):
--- Comment #9 from sgk at troutmask dot apl dot washington dot edu
2007-12-20 22:27 ---
Subject: Re: DTIME returns total process time and not since last invocation
On Thu, Dec 20, 2007 at 09:39:29PM -, dfranke at gcc dot gnu dot org wrote:
Daniel, are you working on this PR?
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-12-20 22:33
---
From Note 13.8:
The start time is left imprecise because the purpose is to time
sections of code, as in the example.
Thanks for pointing it out. I'll re-add this fallback to CPU_TIME.
--
templateclass _T2 struct X {
templateclass _U2 X(_U2 __y){}
};
template class T class Y{};
template class Yvoid {
typedef enum {} Z;
Y():z(), x(z) {}
Z z;
XZ x;
};
g++-4.3.0 -c test.cpp
test.cpp: In constructor 'Yvoid::Y()':
test.cpp:10: internal
--- Comment #1 from rbuergel at web dot de 2007-12-20 22:47 ---
gcc version 4.3.0 20071213 (experimental) (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34541
The testcase gcc.c-torture/compile/20071117-1.c fails on both
powerpc-apple-darwin* and powerpc64-unknown-linux-gnu at -O0. The failure on
powerpc-apple-darwin9 appears as...
Executing on host:
/sw/src/fink.build/gcc43-4.2.999-20071219/darwin_objdir/gcc/xgcc
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-20 22:55 ---
*** This bug has been marked as a duplicate of 34393 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-12-20 22:55 ---
*** Bug 34542 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jakub at gcc dot gnu dot org 2007-12-20 23:13 ---
Can we close this now, or do you want to keep it around until you get core
feedback?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34111
--- Comment #3 from hjl at lucon dot org 2007-12-21 00:25 ---
I configured gcc with
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
\
--enable-shared \
--enable-threads=posix \
--enable-haifa \
--- Comment #8 from dje at gcc dot gnu dot org 2007-12-21 00:29 ---
The issue is whether to default G++ to _LARGE_FILES, as is done for Fortran,
and perform all libstdc++ I/O as 64-bit operations, which will affect
performance. Not everyone may want or need large I/O. There is no way
The gcc.dg/out-of-bounds-1.c testcase fails on powerpc-apple-darwin9 with the
error...
Executing on host:
/sw/src/fink.build/gcc43-4.2.999-20071219/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc43-4.2.999-20071219
/darwin_objdir/gcc/
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-21 00:51 ---
This testcase should be running for powerpc*-*-linux* and powerpc*-*-elf*
targets.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2007-12-21
00:54 ---
It does compile fine on powerpc-apple-darwin9 without the -mstrict-align. FYI.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34543
make[4]: Entering directory
`/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/boehm-gc
'
pthread_default_stacksize_np failed.
/bin/sh[9]: 407 Bus error(coredump)
FAIL: gctest
I believe that the fail is expected.
--
Summary: pthread_default_stacksize_np failed.
Product: gcc
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2007-12-21 03:00
---
It works fine on ppc64-linux-gnu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34482
--- Comment #41 from danglin at gcc dot gnu dot org 2007-12-21 03:06
---
Subject: Bug 34003
Author: danglin
Date: Fri Dec 21 03:05:43 2007
New Revision: 131114
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131114
Log:
PR bootstrap/34003
* c-decl.c (merge_decls):
--- Comment #42 from danglin at gcc dot gnu dot org 2007-12-21 03:07
---
Fixed on all active branches.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-12-21 03:13
---
This is a regression. The test case is OK with 4.2
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from bugzilla-gcc at thewrittenword dot com 2007-12-21
03:59 ---
(In reply to comment #8)
The issue is whether to default G++ to _LARGE_FILES, as is done for Fortran,
and perform all libstdc++ I/O as 64-bit operations, which will affect
performance. Not everyone may
--- Comment #7 from jason at gcc dot gnu dot org 2007-12-21 04:10 ---
We can close it. The core feedback I'm interested in is about the testcase for
Bug 17431, not this one.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Overview Description: ICE when compiling source code.
Steps to Reproduce: Download code from
http://www.k9shrink.com/kmeans.f90
and compile with
gfortran -Wall -v -save-temps kmeans.f90
What happens is ICE with segmentation fault.
Actual Results: ICE
Expected Results: compilation or
--- Comment #1 from jon_d_r at msn dot com 2007-12-21 04:50 ---
Created an attachment (id=14803)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14803action=view)
Source code that causes ICE
This is the code that caused the ICE.
--
--- Comment #2 from jon_d_r at msn dot com 2007-12-21 04:57 ---
Downloaded and installed later version of gfortran.
GNU F95 (GCC) version 4.3.0 20071130 (experimental) [trunk revision 130537]
I still get ICE:
G:\fortran\KMeansClustgfortran -v -Wall -save-temps kmeans.f90
Driving:
--- 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
--- Comment #4 from kargl at gcc dot gnu dot org 2007-12-21 06:14 ---
Here's a reduced testcase.
module const_mod
implicit none
integer, parameter :: mp = selected_real_kind(15,300)
end module const_mod
module blk1_mod
implicit none
integer :: numclusters = 2
end module
--- Comment #7 from steven at gcc dot gnu dot org 2007-12-21 07:28 ---
Lee,
Patch was rejected: http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00976.html
Was it your plan to give it another try from behind the drawing board? :-)
--
steven at gcc dot gnu dot org changed:
--- Comment #7 from steven at gcc dot gnu dot org 2007-12-21 07:30 ---
Ollie, ping?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27078
--- Comment #5 from burnus at gcc dot gnu dot org 2007-12-21 07:39 ---
valgrind:
==6521== Invalid read of size 1
==6521==at 0x49C7D0: gfc_get_symbol_decl (trans-decl.c:899)
==6521==by 0x4A47DC: gfc_conv_variable (trans-expr.c:424)
==6521==by 0x4A7079:
100 matches
Mail list logo
