--- Comment #2 from freddyz77 at tin dot it 2006-01-06 09:14 ---
Well, I don't know why but looking more deeply I still don't understand
$ gdb /opt/gcc42/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1
GNU gdb Red Hat Linux (6.3.0.0-1.84rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is f
--- Comment #6 from amodra at bigpond dot net dot au 2006-01-06 09:31
---
In answer to comment #1, using just the upper double of the TFmode long double
*is* rounding to double. As David says in #5, the upper double is the value of
the long double rounded to double..
--
http://gcc
[ foo.cpp ]
struct Var {
operator int() const;
Var& operator = (int);
bool operator == (int);
};
bool operator == (int, Var&);
void foo(Var var)
{
if (var = 0); // if (var.operator=(0))
}
[ foo.cpp.t03.gimple ]
void foo(Var) (var)
{
bool retval.0;
struct Var & D.1768;
int
Source (test.c):
struct type {
char dummy;
} a[2];
void test( void ) {
struct type* b = &a[1];
}
compiler call:
mcore-gcc test.c -c
output:
test.c: In function 'test':
test.c:7: error: unrecognizable insn:
(insn 8 6 9 3 (set (reg:SI 25)
(const:SI (plus:SI (symbol_ref:SI ("a") )
--- Comment #1 from olaf at bonorden dot de 2006-01-06 09:56 ---
Don't know the exact version of gcc, i do a svn checkout yesterday.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25690
Hi,
I am not sure is this a bug or not !.
Here is my code, very simple
///
#include
int main ()
{
floata;
floatb;
int i;
a = 10.97;
b = 0.0;
for (i=0; i < 30; i++) {
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 12:32 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 12:34 ---
This is current installation problem of your current GCC and binutils. Sounds
like you don't have GNU binutils installed.
This is not a GCC bug.
--
pinskia at gcc dot gnu dot org changed:
What|R
Segmentation fault when calling a generic procedure like
call bilin_interpolate(x,y,ixp,iyp,wt_00,wt_01,wt_10,wt_11)
for a interface like:
interface bilin_interpolate
module procedure bilin_interp_array
module procedure bilin_interp_elem
end interface
with:
subroutine bilin_i
--- Comment #1 from Heiko dot Klein at gmx dot net 2006-01-06 13:01 ---
Created an attachment (id=10586)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10586&action=view)
interface and implementation
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25691
--- Comment #2 from Heiko dot Klein at gmx dot net 2006-01-06 13:02 ---
Created an attachment (id=10587)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10587&action=view)
usage of generic procedure
calling of the (currently commented) procedure directly compiles without
problems
--- Comment #6 from joseph at codesourcery dot com 2006-01-06 13:27 ---
Subject: Re: libstdc++ headers should go in multilib
directories
On Fri, 6 Jan 2006, pcarlini at suse dot de wrote:
> > Working on a fix.
>
> Many thanks. I was wondering whether you are aware of another (long s
--- Comment #10 from nathan at gcc dot gnu dot org 2006-01-06 13:39 ---
Created an attachment (id=10588)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10588&action=view)
simplest test case
This appears to be tickling a latent bug in the dwarf code. Before my patch I
discover that
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-06 13:40 ---
*** Bug 25691 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-06 13:40 ---
This reduces to the testcase in PR 22146.
*** This bug has been marked as a duplicate of 22146 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-06 13:56 ---
Confirmed (for now, unless you feel this is an exact dup of bug 18003).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 14:01 ---
Can you attach the full code as I cannot reproduce this with the code you put
into the comment as it just spits out errors.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-06 14:01 ---
I said confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-06 14:07 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 14:07 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|norma
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 14:08 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25683
Hello,
Here is a small sample to repeat the case:
#include
main()
{
double d1, *pd1;
char *c = (char*)&d1;
pd1 = &d1;
((int*)pd1)[0] = -1;
((int*)pd1)[1] = -1;
fprintf(stderr,">> d1 = %lf\n", d1);
fprintf(stderr,">> int: %d %d\n", ((int*)pd1)[0], ((int*)pd1)
--- Comment #1 from fm at 4js dot com 2006-01-06 14:19 ---
Created an attachment (id=10589)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10589&action=view)
Small sample to illustrate the problem
How to repeat sample
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25692
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-06 14:20 ---
You are violating C aliasing rules as you acess d1 via an int.
*** This bug has been marked as a duplicate of 21920 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #81 from pinskia at gcc dot gnu dot org 2006-01-06 14:20
---
*** Bug 25692 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from fm at 4js dot com 2006-01-06 14:46 ---
Maybe...
But I made some tests under Linux X86 and some AIX 64 bits. This code works as
expected everywhere...
So, I wonder why gcc behaviour is différent under this Linux PPC64 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #9 from jb at gcc dot gnu dot org 2006-01-06 14:47 ---
Reopening since many of the intrinsics could still vectorize better.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-06 14:53 ---
(In reply to comment #3)
> Maybe...
>
> But I made some tests under Linux X86 and some AIX 64 bits. This code works as
> expected everywhere...
> So, I wonder why gcc behaviour is différent under this Linux PPC64 ?
The line number given in warning messages for unused variables in a procedure
with an internal procedure, is that of the first line of the internal
procedure, instead of the host procedure. I find this a bit confusing:
erik:~$ cat -n swap.f90
1 subroutine sort()
2 real :: a
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-06 15:00 ---
Subject: Bug 25528
Author: pinskia
Date: Fri Jan 6 15:00:50 2006
New Revision: 109419
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109419
Log:
2006-01-06 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-06 15:01 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 15:01 ---
IIRC the issue is using warning instead of gfc_warning. There is another bug
like this filed for arguments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25693
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-06 15:02 ---
*** Bug 25693 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-06 15:02 ---
Actually the bug is for both, This is a dup of bug 21918.
*** This bug has been marked as a duplicate of 21918 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #7 from pcarlini at suse dot de 2006-01-06 15:12 ---
(In reply to comment #6)
> The bugs seem entirely independent.
Ok, too bad ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25524
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25690
Building a non-bootstrap native gcc with selected target libraries
doesn't work anymore.
on an i686-pc-linux-gnu host in a directory parallel to a unified symlink tree
in ../srcw , I configured with:
../srcw/configure --with-arch=i686
and then started make with:
make all-gcc all-target-libstdc+
--- Comment #1 from drow at gcc dot gnu dot org 2006-01-06 16:35 ---
Subject: Re: New: selective non-bootstrap build broken
On Fri, Jan 06, 2006 at 04:27:16PM -, amylaar at gcc dot gnu dot org wrote:
> Building a non-bootstrap native gcc with selected target libraries
> doesn't wo
We no longer (after toplevel bootstrap) do a comparision between stage2 and
stage3.
--
Summary: [4.2 Regression] bootstrap no longer does a comparision
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 16:39 ---
Oh, I should say we invoke make compare in the gcc directory but that does
nothing since it has no idea it was invoked using toplevel bootstrap.
--
pinskia at gcc dot gnu dot org changed:
What|Rem
--- Comment #4 from Heiko dot Klein at gmx dot net 2006-01-06 17:07 ---
I doubt that it has anything to do with PR 22146. PR 22146 is about elemental,
and I get the same ICE when removing the elemental keyword. I don't get the ICE
when calling the elemental subroutine directly. (See comm
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-01-06 17:27 ---
The toplevel makefile has a target 'all' which allegedly does a native
non-bootstrap build. However, that still does a multi-stage build,
thus building everything that is intended to be debugged with a
compiler that
specs.
Target: powerpc-apple-darwin8.3.0
Configured with: ../gcc/configure --prefix=/Users/dir/gfortran
--enable-languages=c,f95
Thread model: posix
gcc version 4.2.0 20060106 (experimental)
[dranta:~/tests/gfortran-D] dir%
--
Summary: libfortran - Segmentation fault/ Bad Address
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-06 18:49 ---
Reduced testcase:
class bugfinal {
static final int a=0;
void method() {
a++;
}
}
This code is invalid.
Anyways confirmed.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #3 from ian at airs dot com 2006-01-06 19:05 ---
I think this is a bug in simplify_expand_binop (adding Richard Sandiford to the
CC since he introduced that function). Currently when simplify_expand_binop is
given two constants, it calls simplify_gen_binary. When the operat
--- Comment #4 from ian at airs dot com 2006-01-06 19:06 ---
Created an attachment (id=10590)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10590&action=view)
Sample untested patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25662
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfir
I have a SuSe-9.1Pro with gcc-3.3.3 installed. I downloaded/extracted a copy of
gcc-4.0.2.tar.bz2 on my HD. Then, I created an empty directory under the
gcc-4.0.2 directory tree and name it objdir. After entering the objdir
directory, I configured gcc for a compilation as follows:
+
../configu
--- Comment #5 from tromey at gcc dot gnu dot org 2006-01-06 19:34 ---
What is the status of this?
It looks like Bug 24348 might be fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from tromey at gcc dot gnu dot org 2006-01-06 19:39 ---
The fix was checked in a while ago.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from kargl at gcc dot gnu dot org 2006-01-06 20:04 ---
Subject: Bug 25101
Author: kargl
Date: Fri Jan 6 20:04:15 2006
New Revision: 109425
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109425
Log:
2006-01-06 Steven G. Kargl <[EMAIL PROTECTED]>
PR fort
--- Comment #7 from kargl at gcc dot gnu dot org 2006-01-06 20:04 ---
Subject: Bug 24640
Author: kargl
Date: Fri Jan 6 20:04:15 2006
New Revision: 109425
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109425
Log:
2006-01-06 Steven G. Kargl <[EMAIL PROTECTED]>
PR fort
--- Comment #8 from kargl at gcc dot gnu dot org 2006-01-06 20:06 ---
Fixed on 4.1, too.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|A
--- Comment #7 from kargl at gcc dot gnu dot org 2006-01-06 20:07 ---
Fixed on 4.1, too.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Status|A
--- Comment #1 from dir at lanl dot gov 2006-01-06 20:11 ---
Here is a shorter one that also crashes on the Macintosh -
[dranta:~/tests/gfortran-D] dir% gfortran -o write20 write20.f
[dranta:~/tests/gfortran-D] dir% write20
Segmentation fault
[dranta:~/tests/gfortran-D] dir% cat write20
--- Comment #9 from tromey at gcc dot gnu dot org 2006-01-06 20:12 ---
Subject: Bug 23499
Author: tromey
Date: Fri Jan 6 20:12:22 2006
New Revision: 109426
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109426
Log:
PR libgcj/23499:
* lib/Makefile.in: Rebuilt.
--- Comment #5 from dje at gcc dot gnu dot org 2006-01-06 20:18 ---
The patched compiler does build and does fix the testcase.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #9 from rakdver at gcc dot gnu dot org 2006-01-06 20:23 ---
Subject: Bug 18527
Author: rakdver
Date: Fri Jan 6 20:22:56 2006
New Revision: 109427
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109427
Log:
PR tree-optimization/18527
* tree-ssa-loop-ni
--- Comment #10 from tromey at gcc dot gnu dot org 2006-01-06 20:26 ---
Subject: Bug 23499
Author: tromey
Date: Fri Jan 6 20:26:52 2006
New Revision: 109428
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109428
Log:
PR libgcj/23499:
* lib/Makefile.in: Rebuilt.
--- Comment #6 from debian-gcc at lists dot debian dot org 2006-01-06
20:27 ---
(In reply to comment #5)
> Is this fixed?
yes, according to
http://lists.debian.org/debian-gcc/2005/12/msg00220.html
Matthias
--
debian-gcc at lists dot debian dot org changed:
What|R
--- Comment #6 from debian-gcc at lists dot debian dot org 2006-01-06
20:28 ---
(In reply to comment #5)
> What is the status of this?
> It looks like Bug 24348 might be fixed.
correct, the patch for 24348 is checked in.
Matthias
--
debian-gcc at lists dot debian dot org changed
--- Comment #11 from tromey at gcc dot gnu dot org 2006-01-06 20:30 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|R
--- Comment #6 from halcy0n at gentoo dot org 2006-01-06 20:54 ---
I can confirm it fixes it on my box as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25662
The gcj manual does not have an option index.
Also many concepts and functions are not indexed at all.
--
Summary: gcj manual missing option index
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
If you go to the top-level info node, you will see that there
is no direct menu entry for the "g++" command. I think we should
have one, which means adding an @direntry for it.
(See gcc/java/gcj.texi for an example of per-command @direntry use)
More generally I think we should have an @direntry f
One common mistake in C is to do sizeof(x) where x is a pointer and
what was really wanted was sizeof(*x). Similar to requiring
parentheses around assignments in conditionals, I'd like an optional
warning to be added when sizeof is done on a variable that is a
pointer. For example, in the code be
Last time it passed (before PR24994):
LAST_UPDATED: Sun Dec 11 12:10:30 UTC 2005 (revision 108381M)
Now that Ada bootstraps again, it fails:
,.,. CXA4024 ACATS 2.5 06-01-06 22:31:19
CXA4024 Check that the function "-", To_Ranges, To_Domain, and
To_Range are available in the p
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-06 22:12 ---
Actually people use sizeof(x) all the time to mean the correct thing, for an
example: memcpy(&x, y, sizeof(x));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25702
--- Comment #1 from laurent at guerby dot net 2006-01-06 22:15 ---
Now passing on both 4.1 and 4.2 as of
LAST_UPDATED: Fri Jan 6 18:54:39 UTC 2006 (revision 109421)
(it has been working for a while)
--
laurent at guerby dot net changed:
What|Removed
--- Comment #3 from laurent at guerby dot net 2006-01-06 22:18 ---
Is 4.1 or 4.2 building there now?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24356
--- Comment #5 from laurent at guerby dot net 2006-01-06 22:19 ---
Is 4.1 or 4.2 working there?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24468
--- Comment #2 from meklund at cisco dot com 2006-01-06 22:24 ---
Subject: Re: feature request: generate a warning for sizeof on a pointer
On Fri, Jan 06, 2006 at 10:12:55PM -, pinskia at gcc dot gnu dot org wrote:
> Actually people use sizeof(x) all the time to mean the correct th
--- Comment #4 from bugzilla-gcc at thewrittenword dot com 2006-01-06
22:32 ---
(In reply to comment #3)
> Is 4.1 or 4.2 building there now?
Dunno. Will try and find some time to build 4.1 soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24356
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-06
23:04 ---
Subject: Re: Unable to build gnatmake
> --- Comment #3 from laurent at guerby dot net 2006-01-06 22:18 ---
> Is 4.1 or 4.2 building there now?
I see HP has a new libcl patch:
PHSS_33903 - s700_8
--- Comment #6 from bugzilla-gcc at thewrittenword dot com 2006-01-06
23:18 ---
(In reply to comment #5)
> I see HP has a new libcl patch:
>
> PHSS_33903 - s700_800 11.23 LIBCL patch
>
> HP-UX series 700 11.X patch digest,HP-UX series 800 11.X patch digest
> HP-UX,UNIX 2005/12/22 s
* Reduced FORTRAN program form HFS.f in package atsp
* A General Program for Computing Magnetic Dipole and
* Electric Quadrupole Hyperfine Constants
*
* C O P Y R I G H T -- 1994
*
* P. Jonsson and C.G. Wahlstrom, Department of Physics,
*
--- Comment #6 from hp at gcc dot gnu dot org 2006-01-07 00:02 ---
I built and checked cross from i686-pc-linux-gnu to cris-axis-linux-gnu with
this
patch, and built CSiBE-2.1.1 at -O0, -O1, -O2 (note 1) and -O3 compile-time
tests and -Os compile-time and size tests, with just the two ex
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-07
00:10 ---
Subject: Re: Unable to build gnatmake
> --- Comment #3 from laurent at guerby dot net 2006-01-06 22:18 ---
> Is 4.1 or 4.2 building there now?
Albert, it looks like replacing "/usr/lib/libcl.a" w
--- Comment #1 from malitzke at metronets dot com 2006-01-07 00:12 ---
I know that this has no easy solution. However, just stating that this is an
(implicitly) inadmissable case of going from one block to another is not
satisfactory. Please PLEASE!!! do not make this into another case
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-07 00:16 ---
IFC gives a warning:
fortcom: Warning: t.f, line 70: A jump into a block from outside the block may
have occurred. [105]
GO TO 105 ! rmg questionable goto
^
Oh, this is a
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-07 00:16 ---
*** Bug 25705 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #11 from steven at gcc dot gnu dot org 2006-01-07 00:25 ---
The thread starting at http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00373.html
addresses my question in comment #10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23455
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-01-07 00:59
---
Confirmed
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|U
Last known to work with: "Thu Dec 8 10:28:12 UTC 2005 (revision 108225M)".
Known to fail with: "Thu Jan 5 03:26:35 UTC 2006 (revision 109371M)".
For the test-case in the attachment named bug.i, this line is emitted:
mov.w [$r12=$r10+8],$r9
That's an invalid asm; it should have been movs.w or mo
--- Comment #1 from hp at gcc dot gnu dot org 2006-01-07 01:30 ---
Created an attachment (id=10591)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10591&action=view)
test-case
Compile with
./cc1 -fpreprocessed -march=v10 -quiet -O2 -w -fno-strict-aliasing -fno-common
-fomit-frame-p
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org
|dot org |
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-07 04:21 ---
The Duplicated Key problem is actually PR 24558. After fixing that one we
would still have a problem with the return type being a character.
--
pinskia at gcc dot gnu dot org changed:
What|Remove
http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlf101a.doc/xlflr/use.htm
statements like as valid:
use INTRINSIC, ISO_FORTRAN_ENV
end
--
Summary: support for Fortran 2003 USE statements, INTRINSIC and
NONINTRINSIC
Produ
doing something like:
function f()
use modulef
end function
function g()
use modulef
end function
function h()
use modulef
end function
function i()
use modulef
end function
-
Causes us to load in the module 4 times which is just wrong.
--
Summary: Module loading is not good at a
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-07 05:10 ---
Looking at the profile for PR 21130 makes me think fixing this bug will also
fix that one.
Oh. it is just as bad if we have module modulef declared in the same file as we
have to save it and then reload it which is j
For more information see
http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=/com.ibm.xlf101a.doc/xlflr/bindc-attr.htm
(Note I am starting to like XLF's manual).
--
Summary: BIND (Fortran 2003) is not supported at all
Product: gcc
Version: 4
Testcase:
function f()
REAL :: f
f = 1.0
end function
call f
end
-
This is very much related to PR 23308.
The problem here is the main issue why we create two decls for f in the
following program:
function f()
REAL :: f
f = 1.0
end function
g = f()
end
--
Summary: accepts "call"
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-07 05:31 ---
Note I think fixing PR 25710 and the mentioned problem of not keeping symbols
correctly will fix this bug. I have been trying to fix this but it is hard.
Also note we have the same problem with "call" to functions.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-07 05:34 ---
This looks like another case for PR 14771.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-07 05:37 ---
Isn't this just a dup of bug 20861?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25034
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-07 05:43 ---
(In reply to comment #2)
> It seems that, above a given size, gfortran declares the array as non-static:
Does not matter, the front-end is supposed to error out when the array's size
has overflowed.
The DECL_SIZE_UN
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-07 05:47 ---
*** Bug 25686 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-07 05:47 ---
*** This bug has been marked as a duplicate of 22571 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from kargl at gcc dot gnu dot org 2006-01-07 06:05 ---
Please, do not use non-standard documents! You can get a copy
of the Final Committee Draft of the Fortran 2003 standard from
the J3 web site (or you can ask me to send you a copy). Vendors
tend to interpret the stand
100 matches
Mail list logo
