--- Comment #4 from rth at gcc dot gnu dot org 2005-11-02 08:06 ---
Still present in 4.1.
As a guess, we're creating a BLKmode register (because alignof(struct s1)
is less than alignof(HImode)), and assign_parm_setup_block forces the data
into the stack. It's possible this can be
--- Comment #5 from rth at gcc dot gnu dot org 2005-11-02 08:09 ---
And there is nothing Alpha specific about this. Any target which passes
structures in registers can show it. For instance, ia64:
f1:
.prologue
.body
.mmi
st2 [r12] = r32
nop 0
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-02 08:23 ---
That testcase is IMHO invalid (see
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00099.html
), but
void
foo (void)
{
int i;
#pragma omp parallel sections shared (i)
{
#pragma omp section
{
i = 0;
--
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 #2 from giovannibajo at libero dot it 2005-11-02 09:20 ---
Template parameters can't be used in friend declarations (nor in any elaborated
type specifier construct).
--
giovannibajo at libero dot it changed:
What|Removed |Added
--- Comment #3 from rearnsha at gcc dot gnu dot org 2005-11-02 10:13
---
../.././gcc/config/arm/lib1funcs.asm:731: Error: no such instruction: `moveq
pc,lr'
This just shows that you aren't picking up an ARM assembler. Have you
installed GAS correctly? and does the compiler know
--- Comment #5 from pcarlini at suse dot de 2005-11-02 10:29 ---
Fixed for 4.1.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23425
MODULE attribute conflicts with PROCEDURE attribute
this error message is not accurate enough.
The conflicting attribute should be mentionned.
For instance in:
module abc
contain
function abc()
The conflicting attributes is the name of the module and the name of the
function.
this is
--- Comment #3 from thebohemian at gmx dot net 2005-11-02 11:09 ---
Created an attachment (id=10113)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10113action=view)
lazy linker test setup
This is a newer version of the test for class linking. The change is that the
actual tests
--- Comment #8 from alexander_herrmann at yahoo dot com dot au 2005-11-02
11:29 ---
I guessed somebody found it before but searching the db I couldn'n find it.
Anyway shouldn't we make it than dependend or blocking Bug
#tree-optimization/21513
As the funktion while C correct will never
--- Comment #4 from tobi at gcc dot gnu dot org 2005-11-02 12:37 ---
I was curious, and tried below patch, changing .EQV. to .NEQV. in the testcase,
and still we don't get the right result, since our logical type is a real
logical, in that only the lowest bit is considered. I did some
We are using a cross compiler for 64 bit Linux on MIPS yosemite. When we
compile c sources with command: mips64-linux-gnu-gcc -c -gdwarf-2 -mabi=64
xxx.c then the value of atribute in dwarf2 info : DW_AT_high_pc and
DW_AT_low_pc is 0 what is surely wrong
for mips64-linux-gnu-gcc -c -gdwarf-2
--- Comment #6 from ed at eh3 dot com 2005-11-02 13:12 ---
Hi jvdelisle, I'm not sure if it qualifies as high priority but it is one
of the few (only?) gfortran bugs that we've encountered with the MITgcm fluid
flow and transport model (http://mitgcm.org). If it helps, I'll be happy
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 13:15 ---
Full testcase:
module abc
contains
function abc()
i=1
end function
end module
There is actually two problems here, the first is the message about the
conflicts is not very clear. The second issue is that the
--- Comment #2 from anglade at gmail dot com 2005-11-02 13:28 ---
(In reply to comment #1)
Full testcase:
module abc
contains
function abc()
i=1
end function
end module
There is actually two problems here, the first is the message about the
conflicts is not very clear. The
/*
* Summary:
* Wrong statement reordering
* Description:
* If you run this program, it will produce an output of 1.
* The reason is that the assignment V1=0 which should be
* executed before the call to cl_throw() is moved after
* this call, and hence when
--- Comment #1 from jakub at gcc dot gnu dot org 2005-11-02 13:59 ---
Subject: Bug 24613
Author: jakub
Date: Wed Nov 2 13:59:00 2005
New Revision: 106383
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106383
Log:
PR c++/24613
* c-parser.c (c_parser_pragma):
--- Comment #2 from jakub at gcc dot gnu dot org 2005-11-02 14:03 ---
Fixed on the branch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Hi,
as it has bothered me for quite some time, I finally
decided to report. The program
program gfcbug29
stop
end
when compiled with g77, executes and terminates without any message.
*Only* when a stop code is present, as in
stop 0
it (the g77 runtime) says so.
--- Comment #13 from law at redhat dot com 2005-10-31 23:36 ---
Subject: Re: [4.1 Regression] Slowdown of the
bresenham line drawing by roughly 20%
On Mon, 2005-10-31 at 23:25 +, hubicka at ucw dot cz wrote:
See comment #5. The fact that we ended up with more
--- Comment #15 from hubicka at ucw dot cz 2005-11-02 14:32 ---
Subject: Re: [4.1 Regression] Slowdown of the bresenham line drawing by
roughly 20%
--- Comment #13 from law at redhat dot com 2005-10-31 23:36 ---
Subject: Re: [4.1 Regression] Slowdown of the
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-11-02 14:51 ---
I cannot reproduce this on 4.0.1 or CVS HEAD of 4.0 (20050919), nor on 4.1.0.
What optimization options did you use?
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 14:55 ---
I cannot reproduce this with the compiler version you have.
GNU C version 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
(x86_64-linux-gnu)
--
pinskia at gcc dot gnu dot org changed:
What
--
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 2005-11-02 14:59 ---
Confirmed, this is more of a front-end issue than a library issue. As the
front-end emits a call to _gfortran_stop_numeric in both the STOP cases.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 15:05 ---
And works in 4.0.3 but not in 3.4.5 and 3.4.0.
Closing as fixed for 4.0.3 since this was not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 15:14 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 15:19 ---
Are you sure that there are no relocations and that it is zero because of them?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24634
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-02 15:47
---
Here is a further reduced testase:
typedef struct {
union {unsigned Xl_ui;} Ul_i;
union {unsigned Xl_uf;} Ul_f;
} l_fp;
void dolfptoa(short ndec)
{
l_fp work;
work.Ul_f.Xl_uf = 0x535f3d8;
while (ndec 0)
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-02 15:53
---
The following fails with -O1 -fno-tree-sra.
typedef struct {
struct {unsigned Xl_ui;} Ul_i;
struct {unsigned Xl_uf;} Ul_f;
} l_fp;
void dolfptoa(short ndec)
{
l_fp work;
work.Ul_f.Xl_uf = 0x535f3d8;
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-11-02 16:03
---
Here is another more reduced testcase (still at -O1 -fno-tree-sra):
typedef struct {
unsigned a;
} l_fp;
void dolfptoa(short ndec)
{
l_fp work;
unsigned workUl_fXl_uf;
work.a = 0x535f3d8;
while (ndec 0)
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-02 16:12
---
(In reply to comment #12)
Here is another more reduced testcase (still at -O1 -fno-tree-sra):
That testcase is invalid, the one which is valid:
ypedef struct {
unsigned a;
} l_fp;
void dolfptoa(short ndec)
{
--- Comment #6 from uweigand at gcc dot gnu dot org 2005-11-02 16:22
---
Tested patch in:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00113.html
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
public class Foo {
static MissingClass STATIC_MIA;
}
public class Foo2{
MissingClass NONSTATIC_MIA;
}
Foo and Foo2 should pass the verifier if the bytecode for MissingClass is
absent.
--
Summary: static and non-static declarations of missing type do
not
--- Comment #6 from paolo at gcc dot gnu dot org 2005-11-02 16:24 ---
Subject: Bug 23425
Author: paolo
Date: Wed Nov 2 10:27:54 2005
New Revision: 106379
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106379
Log:
2005-11-02 Thomas Kho [EMAIL PROTECTED]
PR
--- Comment #5 from uweigand at gcc dot gnu dot org 2005-11-02 16:32
---
Confirmed. Looks like a backend problem, I'm working on it.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
Jv_FindClass throws a ClassNotFoundException in case the requested class cannot
be resolved (regardless of whether the bytecode missing or a further dependency
cannot be resolved).
This causes problems because in case of serious bytecode errors (eg. the class
of a field is missing) where a
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-02 16:39
---
This is as far as I can reduce it, -O1:
typedef union {
unsigned a;
} l_fp;
int main(void)
{
l_fp work;
unsigned workUl_fXl_uf = 0x;
int ndec = 10;
do {
ndec--;
work.a = 0;
work.a =
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-02 17:02
---
A link to the changes (so I can be a little lazy):
http://gcc.gnu.org/viewcvs?view=revrev=101841
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24627
--- Comment #9 from janis at gcc dot gnu dot org 2005-11-02 17:15 ---
A regression hunt on powerpc-linux identified this patch:
r100793 | rth | 2005-06-09 07:43:40 + (Thu, 09 Jun 2005) | 38 lines
PR tree-opt/20610
--
janis at gcc dot gnu dot org changed:
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-02 17:16
---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-02 17:16
---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-02 17:16
---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-02 17:16 ---
All P1 enhancements not targeted towards 4.1, moving to P5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from elizabeth dot brosch at thomson dot com 2005-11-02
17:21 ---
Subject: RE: Make Bootstrap fails on AIX 5.2 ML6
I agree. I realized that this was unnecessary. Thanks for the reply.
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-30 17:17
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-02 17:41 ---
Hmm, I would almost want to go on a limb and say this was caused by the patch
for PR 21166. Can you try to revert that patch and try the mainline compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24462
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2005-11-02 17:54
---
Hmm, I would almost want to go on a limb and say this was caused by the patch
for PR 21166. Can you try to revert that patch and try the mainline compiler?
Of course that's it. Thanks for spotting this!
--
--- Comment #9 from rrr6399 at futuretek dot com 2005-11-02 18:17 ---
I imagine code from g95 could be leveraged to support this feature couldn't it?
This is a really important feature, especially in corporate environments where
there is usually mix of big-endian and little-endian
--- Comment #11 from rth at gcc dot gnu dot org 2005-11-02 18:20 ---
Subject: Bug 24178
Author: rth
Date: Wed Nov 2 18:20:07 2005
New Revision: 106388
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106388
Log:
PR target/24178
* config/alpha/alpha.c
--- Comment #2 from kargl at gcc dot gnu dot org 2005-11-02 18:27 ---
This has bugged me also. For a patch, see
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00122.html
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-11-02 18:30
---
Subject: Bug 24569
Author: mmitchel
Date: Wed Nov 2 18:30:26 2005
New Revision: 106392
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106392
Log:
PR c++/24569
* pt.c (instantiate_decl): Use
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-11-02 18:32
---
Subject: Bug 24569
Author: mmitchel
Date: Wed Nov 2 18:32:09 2005
New Revision: 106393
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106393
Log:
PR c++/24569
* pt.c (instantiate_decl): Use
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-11-02 18:36
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
To get a better feeling for the issues which have been reported, this meta-bug
should get the better feeling for them.
--
Summary: [meta-bug] bug to track all uninit variable issues
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||5035, 10138, 16865, 17506,
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 19:00 ---
There are at least 19 bugs related to the uninit warnings.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 19:01 ---
Adding Jeff Law and Diego so they know what the bug numbers are.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
$ cat test.f90
10: a=10
end
$ gfortran test.f90
In file ice.f90:1
20:a=10
1
Warning: Ignoring bad statement label at (1)
ice.f90: In function MAIN__:
ice.f90:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-02 19:17 ---
Some more, this time closed ones. There are many more.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janis at gcc dot gnu dot org 2005-11-02 19:18 ---
A regression hunt using a cross compiler identified the following patch:
r105306 | rth | 2005-10-12 16:29:35 + (Wed, 12 Oct 2005) | 3 lines
PR rtl-opt/23324
* cfgexpand.c
$ cat test_cmt.f90
program test_comments
real ::
a
end program test_comments
$ This is a valid code (i think) checked against Lahey's syntax checker,
getting rejected by gfortran.
$ gfortran test_cmt.f90
In file test_cmt.f90:2
real ::
1
Error: Syntax
The following code should produce random numbers between 0..2^5-1:
import java.math.BigInteger;
import java.security.SecureRandom;
class RndTest {
public static void main(String[] args) {
SecureRandom rnd = new SecureRandom();
for (int i = 0; i 10; i++)
--- Comment #16 from dnovillo at gcc dot gnu dot org 2005-11-02 19:40
---
testing patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24627
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 19:43 ---
This is related to PR 24481.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from h dot b dot furuseth at usit dot uio dot no 2005-11-02
19:52 ---
I think I'd appreciate that warning when writing portable code:
The warning can be useful if the 1 is replaced with a macro
which may or may not expand to 1, or an enum defined in an #ifdef,
or an
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-02 20:01 ---
This does not warn for me on the mainline.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20021
--- Comment #2 from uweigand at gcc dot gnu dot org 2005-11-02 20:27
---
Clearly a backend bug. Working on it ...
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
gfortran issues an Unclassifiable statement error when trying
to compile a statement with concatenation of substrings of
character variables.
--
Summary: Unclassifiable statement on character substring
concatenation
Product: gcc
Version:
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2005-11-02
20:36 ---
Created an attachment (id=10114)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10114action=view)
Test case for this bug
Test case added.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24643
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 20:39 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CONFIG_DEBUG_SPINLOCK and adding a few extra printk will show this:
Linux version 2.6.14 ([EMAIL PROTECTED]) (gcc version 4.1.0 20051102
(experimental)) #61 SMP Wed Nov 2 19:47:05 UTC 2005
Memory: 495732k/524288k available (5004k kernel code, 27528k reserved, 1340k
data, 2394k bss, 380k init
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-02 20:42 ---
[EMAIL PROTECTED]:~/src/gcc ../gcc/build/gcc/f951 -quiet -fsyntax-only
Warning: Reading file 'stdin' as free form.
PROGRAM TABLES
IMPLICIT CHARACTER*8(Y)
YBTABLE=Ylocal(1:2)
END
[EMAIL
Especially now, after fixing a couple of correctness issues, it's obvious that
all the arithmetic inserters/extractors share a common body which should be
commonized to templatized _M_insert/_M_extract, in complete analogy with
_M_insert_int/_M_extract_int, for example, in the num_put/num_get
--- Comment #1 from olh at suse dot de 2005-11-02 20:49 ---
Created an attachment (id=10115)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10115action=view)
PR24644.tar.bz2
buildscripts, preprocessed files, kernel .config and debug patches, bootlog.
building with -O1 does not fix
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-02 21:01
---
Subject: Bug 18157
Author: pinskia
Date: Wed Nov 2 21:01:54 2005
New Revision: 106396
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106396
Log:
2005-11-02 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #10 from mrs at apple dot com 2005-11-02 21:04 ---
Radar 3843157
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17964
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24584
--- Comment #14 from pinskia at gcc dot gnu dot org 2005-11-02 21:12
---
Subject: Bug 18157
Author: pinskia
Date: Wed Nov 2 21:12:27 2005
New Revision: 106397
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106397
Log:
2005-11-02 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #15 from pinskia at gcc dot gnu dot org 2005-11-02 21:12
---
Fixed in 4.0.3 and above, thanks for your report.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tkoenig at gcc dot gnu dot org 2005-11-02 21:13 ---
g77 groks this:
$ cat grg.f
PROGRAM TABLES
IMPLICIT CHARACTER*8(Y)
WRITE(YLOCAL,'(I2.2)') ILOCAL
YBTABLE=Ylocal(1:2)
END
$ g77 grg.f
$
--
tkoenig at gcc dot gnu dot org changed:
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-02 21:13 ---
Note there are still some more 2k5/6 SPEC blocking bugs which just had not been
filed yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15502
--- Comment #7 from tkoenig at gcc dot gnu dot org 2005-11-02 21:17 ---
g77 gets confused by the errors, then bails out:
$ g77 d2ds.f
$ g77 d2ds.f 21 | tail
2
Argument #4 of `maxval' is one type at (2) but is some other type at (1) [info
-f g77 M GLOBALS]
d2ds.f:831:
--- Comment #10 from tkoenig at gcc dot gnu dot org 2005-11-02 21:20
---
(In reply to comment #9)
I imagine code from g95 could be leveraged to support this feature couldn't
it?
Rather not. The libraries have diverged pretty much so it is probably
easier to write this from
--- Comment #1 from tkoenig at gcc dot gnu dot org 2005-11-02 21:24 ---
$ cat foo.f
REAL :: st1
st1(I)=I**2 ! I implicitly typed to integer
REAL :: I
END
$ g77 foo.f
foo.f: In program `MAIN__':
foo.f:2:
st1(I)=I**2 ! I
--- Comment #1 from tkoenig at gcc dot gnu dot org 2005-11-02 21:28 ---
This is only in free-form:
$ cat tst.f
10: a=10
end
$ gfortran tst.f
In file tst.f:1
10: a=10
1
Error: Non-numeric character in statement label at (1)
Confirmed.
--
tkoenig at gcc dot gnu dot
--- Comment #12 from mmitchel at gcc dot gnu dot org 2005-11-02 21:34
---
Subject: Bug 19253
Author: mmitchel
Date: Wed Nov 2 21:34:51 2005
New Revision: 106398
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=106398
Log:
PR c++/19253
* parser.c
1 - 100 of 183 matches
Mail list logo
