--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-19 08:42 ---
Jason, how could we avoid creating the type dependent CALL_EXPR_FN?
It is created by build_new_method_call, but for templates both args and
instance
are going through build_non_dependent_expr which modifies them.
--
The complete, though minimal, sample code will be attached to the bug report.
Since the problem only occurs when using multiple compilation units, the tar
contains multiple files. Note that the code is entirely self-contained. The tar
file contains a script BuildFail.sh that reproduces the error.
I just had a look at some of the source code of the Java package in
the GNU gcc version 4.4.0 snapshot 20081114
gcc-4.4-20081114/libjava/classpath/gnu/classpath/jdwp/transport/SocketTransport.java:99
Using equalsIgnoreCase() is cleaner than using
toUpperCase/toLowerCase().equals().
--- Comment #1 from j dot s dot wijnhout at lumc dot nl 2008-11-19 10:37
---
Created an attachment (id=16721)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16721action=view)
Self-contained example reproducing the error.
Self-contained example reproducing the error.
Scripts to
--- Comment #11 from ams at gcc dot gnu dot org 2008-11-19 12:03 ---
The patch just committed should fix this issue.
The patch discussion is here:
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00641.html
--
ams at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from dominiq at lps dot ens dot fr 2008-11-19 12:40 ---
I don't know if the code in comment #0 is valid or not, but if the file
h5global.mod does not exist compiling it with gfortran r141995 gives:
pr38171.f90:2.14:
USE H5GLOBAL
1
Fatal Error: Can't open
--- Comment #2 from jv244 at cam dot ac dot uk 2008-11-19 13:08 ---
(In reply to comment #1)
SUBROUTINE S(b,i,j)
INTEGER, DIMENSION(:) :: b
integer res(1)
INTEGER :: i,j
res = MINLOC(b(i:j))
END SUBROUTINE S
right.. the 'orginal' testcase was. Actually, these temps are all
--- Comment #2 from jv244 at cam dot ac dot uk 2008-11-19 13:18 ---
(In reply to comment #1)
Do you know of any compilers that catch this? As you say, it is not so easy
to
fix.
I believe ifort gets this right (compiled with 'ifort -S -heap-arrays 64), but
this is just looking at
--- Comment #10 from ams at gcc dot gnu dot org 2008-11-19 11:25 ---
Subject: Bug 36133
Author: ams
Date: Wed Nov 19 11:23:28 2008
New Revision: 141999
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141999
Log:
2008-11-19 Andrew Stubbs [EMAIL PROTECTED]
gcc/
PR
--- Comment #10 from jakub at gcc dot gnu dot org 2008-11-19 13:05 ---
Subject: Bug 36038
Author: jakub
Date: Wed Nov 19 13:03:43 2008
New Revision: 142000
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142000
Log:
PR tree-optimization/36038
*
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-19
14:51 ---
Subject: Re: gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized
conststaticvariable 1
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-18 23:17 ---
IMHO if a target
--- Comment #22 from karol at mikronika dot com dot pl 2008-11-19 15:13
---
(In reply to comment #2)
Reduced testcase:
struct a{~a();a();};
int GetMetaCombination (int a2)
{
a bi;
switch (a2)
{
case 1:
return 18;
break;//removing this works around the
--- Comment #4 from murali dot vemulapati at gmail dot com 2008-11-19
15:38 ---
I updated to svn rev 141991 which has the above changes and did a bootstrap.
The problem with compiling stc++.h seems to have been resolved. I get another
error as follows in libssp:
libtool: link:
--- Comment #2 from razya at il dot ibm dot com 2008-11-19 16:00 ---
(In reply to comment #1)
(In reply to comment #0)
testsuite/gcc.dg/tree-ssa/update-unswitch-1.c is failing when compiled with
-ftree-parallelize-loops=4
In function âblaâ:
--- Comment #3 from razya at gcc dot gnu dot org 2008-11-19 16:09 ---
Subject: Bug 38156
Author: razya
Date: Wed Nov 19 16:08:01 2008
New Revision: 142004
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142004
Log:
2008-11-19 Razya Ladelsky [EMAIL PROTECTED]
PR
--- Comment #7 from pault at gcc dot gnu dot org 2008-11-19 16:21 ---
(In reply to comment #6)
I don't know if the code in comment #0 is valid or not, but if the file
h5global.mod does not exist compiling it with gfortran r141995 gives:
pr38171.f90:2.14:
USE H5GLOBAL
--- Comment #5 from dominiq at lps dot ens dot fr 2008-11-19 16:29 ---
On powerpc-apple-darwin9 I have the same kind of error as reported in comment
#4:
/var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cctJDhJw.s:21:non-relocatable
subtraction expression, _procptr minus
During a compile of gcc 4.3.2 through gentoo's portage with or without
gentoo-specific patches, and cflags of -march=native -O2 -pipe on an amdfam10
processor, an internal compiler error occurs consistently:
/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/sbitmap.c: In function
--- Comment #19 from rguenther at suse dot de 2008-11-19 17:43 ---
Subject: Re: [4.4 Regression] ICE in vectorizer with
restrict pointer
On Tue, 18 Nov 2008, jakub at gcc dot gnu dot org wrote:
--- Comment #18 from jakub at gcc dot gnu dot org 2008-11-18 20:13
---
--- Comment #2 from espindola at google dot com 2008-11-19 17:49 ---
To reproduce:
g++ -O2 -c thunk.C -flto-single -o thunk-lto.o
g++ -O2 -c thunk.C -o thunk.o
readelf -s thunk.o | grep Th
35: 6 FUNCWEAK DEFAULT 19 _ZThn8_N1C1fEv
readelf -s thunk-lto.o
--- Comment #3 from espindola at google dot com 2008-11-19 17:53 ---
This case can be easily fixed by setting targetm.asm_out.can_output_mi_thunk to
NULL. This will introduce a performance regression.
The only case that will be missing is varg functions.
The llvm equivalent bug is
--- Comment #1 from espindola at google dot com 2008-11-19 17:47 ---
Created an attachment (id=16722)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16722action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37352
--- Comment #8 from hjl dot tools at gmail dot com 2008-11-19 18:09 ---
I think we need to break OVERRIDE_OPTIONS into 2 parts:
1. Execute only once for a given input.
2. Execute every time after all optimization options
are processed.
with things like OVERRIDE_OPTIONS_ONCE and
we have to fix g++.dg/opt/devirt1.C
--
Summary: devirtualization is missing in lto
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu
--- Comment #9 from ro at techfak dot uni-bielefeld dot de 2008-11-19
18:05 ---
Subject: Re: libgomp.c++/ctor-9.C failure
ro at techfak dot uni-bielefeld dot de writes:
jakub at gcc dot gnu dot org writes:
Anyway, the following patch fixes this in a cross from x86_64-linux to
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2008-11-19 18:51
---
I'm a bit unsure how to test this right now: what I find is that C objects
have read-only .eh_frame sections and use .cfi* directives, while C++, Java
and Ada objects have read-write .eh_frame sections and
This affects both C and C++ (and probably Objective C that I never used)
(In fact, I propose two warnings:
1. macro parameter is not a whole expression within macro body
2. expanded macro body is not a whole expression within macro use context
)
I propose to add a warning (and include it in
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-19 18:57 ---
The expanded text for the first one is:
int t = 1|2 0xFF00 ? dothis(1|2) : dothat(1|2);
Maybe I am missing something here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38179
--- Comment #8 from jason at gcc dot gnu dot org 2008-11-19 19:29 ---
Subject: Bug 37256
Author: jason
Date: Wed Nov 19 19:27:29 2008
New Revision: 142014
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142014
Log:
PR c++/37256
* pt.c (instantiate_decl): Don't
--- Comment #12 from ubizjak at gmail dot com 2008-11-19 19:32 ---
Created an attachment (id=16723)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16723action=view)
Da patch.
Jack, can you try attached patch?
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #14 from tkoenig at gcc dot gnu dot org 2008-11-19 19:33
---
The problem is fixed on trunk, I think we can close this
after backporting.
Mikael, if you think the problem you mentioned in comment #4 warrants
its own PR, maybe you could open it.
--
--- Comment #3 from jason at gcc dot gnu dot org 2008-11-19 19:38 ---
Subject: Bug 37563
Author: jason
Date: Wed Nov 19 19:36:38 2008
New Revision: 142015
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142015
Log:
PR c++/37563
* parser.c
--- Comment #9 from jason at gcc dot gnu dot org 2008-11-19 19:41 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
While constant initializer reads are folded CCP doesn't propagate the following
in one invocation but requires a second CCP pass to clean up.
/* { dg-do compile } */
/* { dg-options -O -fdump-tree-ccp1 } */
static const int x;
int foo()
{
int *p = x;
int y = *p;
return y + 1;
}
/* {
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-19 20:01 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-19 20:02 ---
Visiting statement:
p_1 = x;
which is likely CONSTANT
Lattice value changed to CONSTANT x. Adding SSA edges to worklist.
Visiting statement:
y_2 = *p_1;
which is likely CONSTANT
Lattice value changed to VARYING.
in the function F1 below, gfortran generates calls to _gfortran_size1 which (I
believe) makes that function about a factor 2-3 slower than should be. In
principle the optimizer should/could realize that size(a) is invariant, and at
least move it out of the loop.
cat test.f90
INTEGER FUNCTION
--- Comment #1 from aran at 100acres dot us 2008-11-19 20:32 ---
Created an attachment (id=16724)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16724action=view)
Patch for stddef.h
This patch ensures that _ANSI_H_ is defined after including machine/ansi.h.
--
GCC fails on NetBSD 5.x because stddef.h assumes that machine/ansi.h defines
_ANSI_H_ as its code guard. This prevents the definition of size_t.
--
Summary: stddef.h assumes machinee/ansi.h defines _ANSI_H_
Product: gcc
Version: 4.4.0
Status:
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-19 20:39 ---
Why is size1 not always inlined? Why is a new temporary array descriptor
constructed and passed instead of using that for a? Note that the latter
cannot be optimized by the compiler. Note that this is also the
Consider the following:
struct s { double x; double y; };
double f(struct s s) { return s.x + s.y; }
When compiled with optimisation, this generates:
f:
movsd %xmm1, -8(%rsp)
addsd %xmm1, %xmm0
ret
What is the movsd doing here ?
--
--
jch at pps dot jussieu dot fr changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38183
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-19 20:49 ---
It works on the trunk for x86_64 darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38183
This is a clone of PR38135.
Reduced (a bit) testcase:
integer, parameter :: N = 3
integer A(N,N)
A(1:N,1:N)=reshape([integer::],[N,N],[1,2,2,2])
write(*,'(3i5)') A
end
--
Summary: invariant RESHAPE not expanded if SOURCE is empty
Product: gcc
Version: 4.4.0
--- Comment #15 from mikael at gcc dot gnu dot org 2008-11-19 20:56 ---
(In reply to comment #14)
Mikael, if you think the problem you mentioned in comment #4 warrants
its own PR, maybe you could open it.
PR 38184 opened for that.
--
--- Comment #1 from mikael at gcc dot gnu dot org 2008-11-19 20:57 ---
(In reply to comment #0)
This is a clone of PR38135.
Path posted there:
Index: simplify.c
===
--- simplify.c (révision 141833)
+++ simplify.c
--- Comment #4 from jason at gcc dot gnu dot org 2008-11-19 21:01 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jason at gcc dot gnu dot org 2008-11-19 21:01 ---
Subject: Bug 37563
Author: jason
Date: Wed Nov 19 21:00:23 2008
New Revision: 142016
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142016
Log:
PR c++/37563
* parser.c
--- Comment #15 from jakub at gcc dot gnu dot org 2008-11-19 21:12 ---
The advantage of such a RTL pass (or just adding such optimization to another
RTL pass) would be that it would handle also say:
struct S
{
char a;
char b;
char c;
char d;
} u __attribute__((aligned));
void
--- Comment #13 from ubizjak at gmail dot com 2008-11-19 21:17 ---
(In reply to comment #12)
Created an attachment (id=16723)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16723action=view) [edit]
Da patch.
Jack, can you try attached patch?
Patch at
--- Comment #4 from vmakarov at gcc dot gnu dot org 2008-11-19 21:22
---
Subject: Bug 37790
Author: vmakarov
Date: Wed Nov 19 21:20:44 2008
New Revision: 142017
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142017
Log:
2008-11-15 Vladimir Makarov [EMAIL PROTECTED]
PR
--- Comment #3 from vmakarov at gcc dot gnu dot org 2008-11-19 21:26
---
Subject: Bug 37859
Author: vmakarov
Date: Wed Nov 19 21:25:00 2008
New Revision: 142018
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142018
Log:
2008-11-19 Vladimir Makarov [EMAIL PROTECTED]
PR
--- Comment #7 from dodji at gcc dot gnu dot org 2008-11-19 21:27 ---
Posted a patch at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00956.html
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jason at gcc dot gnu dot org 2008-11-19 21:28 ---
Member version of PR 35315.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410
--- Comment #4 from nemet at gcc dot gnu dot org 2008-11-19 21:35 ---
Fixed.
--
nemet at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #4 from jason at gcc dot gnu dot org 2008-11-19 21:36 ---
Subject: Bug 36410
Author: jason
Date: Wed Nov 19 21:35:27 2008
New Revision: 142019
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142019
Log:
PR c++/36410
* decl2.c (grokfield): Pass
--- Comment #2 from dominiq at lps dot ens dot fr 2008-11-19 21:38 ---
It seems that the problem is a missed vectorization. For
INTEGER FUNCTION F1(a)
integer :: a(:,:), m, n
m=SIZE(a,1)
n=SIZE(a,2)
F1=0
DO k=1,n
DO j=1,m
F1=F1+a(j,k)
ENDDO
ENDDO
END FUNCTION F1
I
--- Comment #61 from jason at gcc dot gnu dot org 2008-11-19 21:42 ---
Created an attachment (id=16725)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16725action=view)
Compiler patch to allow try/catch and rethrow under -fno-exceptions
I've attached a proposed patch to ignore
--- Comment #5 from jason at gcc dot gnu dot org 2008-11-19 21:47 ---
Fixed in 4.4. Reopen the bug if you want it fixed in 4.3 as well.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
PR 35107 appears to have regressed on mainline. It was originally fixed
on the trunk and 4.3 back in February:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35107
http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00187.html
The summary is that gmp and mpfr and unnecessarily linked into all
executables
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.2.4 4.3.3
Known to work||4.4.0
--- Comment #7 from jason at gcc dot gnu dot org 2008-11-19 21:56 ---
I'll poke at this.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dodji at gcc dot gnu dot org 2008-11-19 22:28 ---
Subject: Bug 35405
Author: dodji
Date: Wed Nov 19 22:26:56 2008
New Revision: 142022
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142022
Log:
gcc/cp/ChangeLog:
2008-11-19 Dodji Seketeli [EMAIL PROTECTED]
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-19 22:32 ---
Certainly in this case inlining size1 is a good idea and easily doable.
The reason why the actual argument's descriptor isn't used is that it might
have different lower bounds (while size doesn't care about that,
--- Comment #9 from dodji at gcc dot gnu dot org 2008-11-19 22:37 ---
Subject: Bug 35405
Author: dodji
Date: Wed Nov 19 22:36:31 2008
New Revision: 142023
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142023
Log:
gcc/cp/ChangeLog:
2008-11-18 Dodji Seketeli [EMAIL PROTECTED]
--- Comment #62 from l dot lunak at suse dot cz 2008-11-19 22:41 ---
(In reply to comment #60)
-fno-exceptions is a big hammer. It will break exceptions trying to
pass through code compiled with that flag whether or not that code has
any try/catch constructs. If you might have
--- Comment #10 from dodji at gcc dot gnu dot org 2008-11-19 22:49 ---
Fixed in trunk and gcc-4_3-branch.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-11-19 22:57 ---
We are remapping
(gdb) up
#4 0x08330b6c in remap_type_1 (type=0xb7d835b0, id=0xbfbe96a4)
at /home/richard/src/gcc-4_3-branch/gcc/tree-inline.c:403
403 walk_tree (TYPE_SIZE_UNIT (new), copy_body_r, id,
Setup:
gcc version: 4.2.3
system: Linux RedHat 4, x86-64 CPU, kernel 2.6.9-67.ELsmp
To reproduce:
Compile attached program as follows: g++ -m32 -O2 -g a.ii and run a.out.
You'll see assert failure on line 11669 of a.ii. If you use -O1 instead of -O2,
the program passes.
I verified that
--- Comment #1 from ddenisen at altera dot com 2008-11-19 23:57 ---
Created an attachment (id=16726)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16726action=view)
Compile with g++ -m32 -O2 a.ii to reproduce the crash
The source code that shows the problem.
--
--- Comment #8 from dodji at gcc dot gnu dot org 2008-11-20 00:02 ---
Subject: Bug 37142
Author: dodji
Date: Thu Nov 20 00:00:39 2008
New Revision: 142025
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142025
Log:
gcc/testsuite/ChangeLog:
2008-11-19 Dodji Seketeli [EMAIL
--- Comment #9 from dodji at gcc dot gnu dot org 2008-11-20 00:06 ---
Subject: Bug 37142
Author: dodji
Date: Thu Nov 20 00:05:04 2008
New Revision: 142026
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142026
Log:
gcc/cp/ChangeLog:
2008-11-19 Dodji Seketeli [EMAIL PROTECTED]
--- Comment #10 from dodji at gcc dot gnu dot org 2008-11-20 00:14 ---
Subject: Bug 37142
Author: dodji
Date: Thu Nov 20 00:13:15 2008
New Revision: 142027
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142027
Log:
gcc/cp/ChangeLog:
2008-11-19 Dodji Seketeli [EMAIL PROTECTED]
--- Comment #11 from dodji at gcc dot gnu dot org 2008-11-20 00:15 ---
Fixed in trunk, 4.3 and 4.2 branches.
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from cnstar9988 at gmail dot com 2008-11-20 00:58 ---
ping...
4.3.3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37263
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2008-11-20
01:10 ---
The patch from Comment 13 when applied to gcc trunk (without a complete
bootstrap) eliminates the failures in gcc.dg-struct-layout-1 at -m64 while not
introducing any at -m32 on i686-apple-darwin9. I am
--- Comment #10 from jakub at gcc dot gnu dot org 2008-11-20 01:48 ---
Subject: Bug 36631
Author: jakub
Date: Thu Nov 20 01:47:10 2008
New Revision: 142033
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142033
Log:
PR c++/36631
* gimplify.c (gimplify_call_expr):
--
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
the source code sample:
...
ULONG MON_OnCallGetIndex();
__asm__
(MON_OnCallGetIndex:lwz 3, 0(1)\n\
lwz 4, 4(3)\n\
lwz 3, 124(4)\n\
blr);
...
--
Summary: when using gcc compile the code with option -g3, I
find the inline assemble code
the source code sample:
...
ULONG MON_OnCallGetIndex();
__asm__
(MON_OnCallGetIndex:lwz 3, 0(1)\n\
lwz 4, 4(3)\n\
lwz 3, 124(4)\n\
blr);
...
--
Summary: when using gcc compile the code with option -g3, I
find the inline assemble code
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-11-20 02:38
---
Sounds like it's fixed.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
I am getting unreliable results from a small function using the latest
prepackaged Mac OS build (PPC) available from the wiki download page. The
function behaves correctly if an otherwise irrelevant write statement is added.
When the statement is removed, the function returns gibberish. This is
I don't think INF is the same as infinity. It is most like implict
declared variable with an undefined value.
Sent from my iPhone
On Nov 19, 2008, at 10:52 PM, dojo at masterleep dot com [EMAIL PROTECTED]
wrote:
I am getting unreliable results from a small function using the latest
--- Comment #1 from pinskia at gmail dot com 2008-11-20 07:05 ---
Subject: Re: New: Inconsistent function results depending on irrelevant write
statement
I don't think INF is the same as infinity. It is most like implict
declared variable with an undefined value.
Sent from my
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-20 07:20 ---
I don't think INF is the same as infinity. It is most like implict
declared variable with an undefined value.
Exactly. With IMPLICIT NONE one sees that INF is an (implicitly typed) integer
variable, which has an
85 matches
Mail list logo
