--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-05
06:27 ---
Fixed in 3.4.4.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-05-05
07:11 ---
I'm confused by this report. You use:
*((int32_t *) a.unaligned_int) = 0x123456;
which reads the value of a.unaligned_int, casts it from an integer
to a pointer, and then dereferences the pointer.
The following program causes my gfortran to throw an internal compiler
error. The problem does not occur for N=10, so I gather that it happens
due to a maximum limit on parameter array size.
[niels:~]% cat test.f
MODULE TEST
integer ilocal
integer,parameter :: N=50
--
What|Removed |Added
Known to fail||3.4.3 3.3.5
Known to work||2.95.2 2.96
gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/usr/local/gcc-4.0.0
Thread model: posix
gcc version 4.0.0
chandra.anuradha% gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure
--- Additional Comments From asuraparaju at gmail dot com 2005-05-05 09:14
---
Created an attachment (id=8822)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8822action=view)
A class that uses MMX intrinsics to compute block differences between two video
frames
--
following code doesnt compile with command gcc -c -O2 -o a.o a.c. It compiles
with any other -O flag. The error is:
a.c: In function `main':
a.c:7: error: inconsistent operand constraints in an `asm'
Here is the code:
typedef struct {
unsigned long sig[2];
} sigset_t;
static __inline__
When using -march, wrong tuning flags are selected.
E.g., -march=armv4t selects 'tune_flags' for arm600, instead of
arm7tdmi (or similar). The error is in arm_override_options().
When -march is given, (sel - all_architectures) is calculated.
In contrast, -mcpu calculates (sel - all_cores). This
--- Additional Comments From maarten at contemplated dot nl 2005-05-05
11:49 ---
(In reply to comment #2)
You are completely right, the code above merely demonstrates what happens when
one writes to an illegal address. The correct version,
*((int32_t *) a.unaligned_int32) = 0x123456;
--- Additional Comments From laurent at guerby dot net 2005-05-05 11:56
---
Seems to be fixed on HEAD as of LAST_UPDATED: Thu May 5 08:05:40 UTC 2005
on x86 and x86_64-linux:
http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg00284.html
--- Additional Comments From maarten at contemplated dot nl 2005-05-05
11:56 ---
(In reply to comment #2)
Reading your reply further, I understand that the behavior I observere is
correct and related to the fact that the 'int32_t' type is assumed to be
aligned.
It is not a bug then,
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-05-05
12:01 ---
Reading your reply further, I understand that the behavior I observere is
correct and related to the fact that the 'int32_t' type is assumed to be
aligned.
Right.
It is not a bug then, but merely a
--- Additional Comments From tsv at solvo dot ru 2005-05-05 13:13 ---
I put my code into try/catch block and the exception was successfully caught.
How general EH is supposed to be called? Could it be arch specific?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21285
the code like this:
unsigned short swap16(unsigned short x)
{
asm volatile (xchgb %b0, %h0 : =q (x) : 0 (x));
return x;
}
produces:
swap16: xchgb %dil, %di == %di isn't valid high 8-bit form.
movzwl %di, %eax
ret
IIRC the %rdi, %rsi, %rsp, %rbp
--
What|Removed |Added
CC||mmazur at kernel dot pl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21398
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
13:49 ---
`a', b, c, or d register for the i386. For x86-64 it is equivalent to `r'
class (for 8-bit instructions that
do not use upper halves).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21398
--- Additional Comments From giovannibajo at libero dot it 2005-05-05
13:54 ---
The compiler is allowed to generate syntectic methods as lazy as possible,
which is upon the first actual use. Thus, this is not a bug.
--
What|Removed |Added
--- Additional Comments From schwab at suse dot de 2005-05-05 14:14 ---
I'm seeing the same error in some C++-only packages. The smallest example I
could find is jikes
http://prdownloads.sourceforge.net/jikes/jikes-1.22.tar.bz2:
g++ -O2 -fmessage-length=0 -Wall -o jikes ast.o
--- Additional Comments From pluto at pld-linux dot org 2005-05-05 14:22
---
in online docs i see that q means byte addressable register (a,b,c,d).
in i386.h i see something differ for x86_64. did i miss something in docs?
#define REG_CLASS_FROM_LETTER(C)\
((C) == 'r' ?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
14:24 ---
(In reply to comment #2)
in online docs i see that q means byte addressable register (a,b,c,d).
in i386.h i see something differ for x86_64. did i miss something in docs?
Yes see comment #1 which is a
libstdc++-v3/testsuite/ext/stdio_sync_filebuf/wchar_t/12077.cc ICEs when
compiled on AIX:
libstdc++-v3/testsuite/ext/stdio_sync_filebuf/wchar_t/12077.cc
: In function 'void test01()':
libstdc++-v3/testsuite/ext/stdio_sync_filebuf/wchar_t/12077.cc
:24: error: BB 3 can not throw but has EH edges
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
--- Additional Comments From dje at gcc dot gnu dot org 2005-05-05 14:34
---
Created an attachment (id=8824)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8824action=view)
pre-processed source for 12077.cc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
14:35 ---
Also happens on ppc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399
--- Additional Comments From dje at gcc dot gnu dot org 2005-05-05 14:37
---
The failure appeared April 25.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399
bash-2.05b$ cat tst.c
extern double floor (double);
int
f (float minX)
{
return (int)floor(minX);
}
bash-2.05b$ ./cc1 tst.c -Os
f
Analyzing compilation unitPerforming intraprocedural optimizations
Assembling functions:
f
tst.c: In function f:
tst.c:6: internal compiler error: in
--- Additional Comments From pluto at pld-linux dot org 2005-05-05 14:41
---
(In reply to comment #3)
(In reply to comment #2)
in online docs i see that q means byte addressable register (a,b,c,d).
in i386.h i see something differ for x86_64. did i miss something in docs?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
14:43 ---
Time to update the sources.
This is a dup of bug 21282.
*** This bug has been marked as a duplicate of 21282 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
14:43 ---
*** Bug 21400 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
14:55 ---
Confirmed, reduced testcase:
typedef struct __FILE FILE;
extern C int fputs(const char *, FILE *);
struct a { ~a(); };
void f(FILE* file)
{
a b;
const char* str = a;
fputs(str, file);
}
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
15:01 ---
A slightly more reduced testcase:
typedef struct __FILE FILE;
extern C int fputs(const char *, FILE *);
void f(FILE* file) throw()
{
const char* str = a;
fputs(str, file);
}
The problem is somehow
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org |org
Status|SUSPENDED
The type of a function interface is not taken over from the
MODULE PROCEDURE's which constitute the INTERFACE.
---BUG.f90--- start
module interface_vs_functions_bug
implicit none
private
interface ex1 ! fails, but should be ok
module procedure func1, func2
end interface
The attached C source gives wrong output when compiled with inlined functions
(-O3 or -O2 -finline-functions) with gcc-4.1-20050501 or gcc-4.0.0. Compiling
gives the following warning twice:
dereferencing type-punned pointer will break strict-aliasing rules
The expected output is 0 0, the actual
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-05
15:36 ---
Subject: Bug 21284
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-05 15:36:34
Modified files:
gcc:
--- Additional Comments From gcc at arbruijn dot dds dot nl 2005-05-05
15:38 ---
Created an attachment (id=8825)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8825action=view)
C source exposing problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21402
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-05
15:42 ---
Subject: Bug 21284
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-05 15:42:05
Modified files:
gcc: ChangeLog
gcc/config/avr :
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
16:13 ---
unsigned char * and char * are in two different aliasing sets while char
and unsigned char are in the
same one, well char is every aliasing set.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
16:25 ---
Fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
16:29 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00425.html.
--
What|Removed |Added
--- Additional Comments From aph at gcc dot gnu dot org 2005-05-05 16:33
---
This may be a dup of 20606
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21362
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
16:40 ---
*** This bug has been marked as a duplicate of 18108 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
16:40 ---
*** Bug 21401 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
GCC target triplet|i686-pc-linux-gnu configured|i686-pc-linux-gnu
|with: ../gcc-4.0.0/configure|
|--pref
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-05 16:49
---
This indeed can be fixed. Instead of
#if defined (_NEWLIB_VERSION) || defined (__MINGW32_VERSION)
/* Newlib and MinGW32 do not have mkfifo. */
exit(0);
#else
do something like
#if
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
16:53 ---
Note C and C++ aliasing rules are being violated in the source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21395
A canadian cross of the compiler failed as it tried to link fix-header.
It's using a mix of build and host object files to build this. The Makefile
reads:
# This is nominally a 'build' program, but it's run only when host==build,
# so we can (indeed, must) use $(LIBDEPS) and $(LIBS).
I,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
17:00 ---
Note with the following code, I get back to what it is without -mmx:
union b
{
int i[2];
__m64 j;
}a;
__m64 sum = _mm_set_pi32(0, 0);
for (int j=0 ; j yl ; j++)
{
This test case fails for GCC 3.3.x and GCC 3.4.x at any level of optimization
other than -O0:
extern void abort (void);
char buffer[20];
void foo (char *p, const char *q)
{
int i = 0;
while (q[i])
p[i] =
--- Additional Comments From jakub at gcc dot gnu dot org 2005-05-05 17:11
---
This could be fixed by expanding __builtin_va_start, __builtin_va_copy
and __builtin_va_end in or soon after pass_stdarg.
Then SRA etc. can also optimize va_list handling.
On the other side, tree-stdarg.c
--- Additional Comments From schlie at comcast dot net 2005-05-05 17:19
---
(In reply to comment #2)
unsigned char * and char * are in two different aliasing sets while char
and unsigned char are in the same one, well char is every aliasing set.
Then I can't help but wonder if it may
--- Additional Comments From prw at ceiriog1 dot demon dot co dot uk
2005-05-05 17:23 ---
Bug 21306 is not the same bug. The attached patch FIX1 fixes the
test cases for this bug, but not for 21306 - you will need to look
at the test case for that bug.
--
--- Additional Comments From ericw at evcohs dot com 2005-05-05 17:25
---
(In reply to comment #2)
Bootstrapping avr-rtems w/ f95 enabled trips a similar or may-be the same bug
(also a target which probably doesn't provide REAL 8).
As a side note, it is known that Fortran does not
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From janis at gcc dot gnu dot org 2005-05-05 17:49
---
A workaround is to replace the body of the loop with:
{
p[i] = q[i];
i++;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21404
--- Additional Comments From law at redhat dot com 2005-05-05 18:01 ---
I know what's causing this and I'm testing a fix now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21380
--- Additional Comments From ericw at evcohs dot com 2005-05-05 18:09
---
Will someone with the requisite permissions please set this bug to NEW? This has
been confirmed.
Thanks
Eric
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
18:12 ---
This is invalid, there is no sequence point between the access of i and the
increment of i so either can
be first.
With -W -Wall we get a warning:
t.c:8: warning: operation on `i' may be undefined
***
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
18:12 ---
*** Bug 21404 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
On May 5, 2005, at 1:19 PM, schlie at comcast dot net wrote:
--- Additional Comments From schlie at comcast dot net 2005-05-05
17:19 ---
(In reply to comment #2)
unsigned char * and char * are in two different aliasing sets
while char
and unsigned char are in the same one, well char is
--- Additional Comments From pinskia at physics dot uc dot edu 2005-05-05
18:41 ---
Subject: Re: wrong-code with inlining and type-punned pointer
On May 5, 2005, at 1:19 PM, schlie at comcast dot net wrote:
--- Additional Comments From schlie at comcast dot net 2005-05-05
--- Additional Comments From tsv at solvo dot ru 2005-05-05 19:07 ---
gcc version 4.0.0 20050423 (Red Hat 4.0.0-2)
Here is another test case that generates unaligned access exception:
typedef union
{
short i16;
unsigned short u16;
int
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-05
19:08 ---
Subject: Bug 21352
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-05 19:08:14
Modified files:
gcc/cp : ChangeLog pt.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
19:10 ---
(In reply to comment #17)
gcc version 4.0.0 20050423 (Red Hat 4.0.0-2)
Here is another test case that generates unaligned access exception:
That code is invalid due to the alignment requirements in
--- Additional Comments From tsv at solvo dot ru 2005-05-05 19:16 ---
I just extracted it from dbus package which I am testing on linux/alpha
platform. There are other packages (mozilla one of them) that started to
generate unaligned access exceptions then built by gcc 4.0.
Should not
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
19:22 ---
(In reply to comment #19)
Should not be some warning to be generated?
There is a warning if going directly from char * to the union pointer but since
you go through a void
pointer, the warning is gone.
--- Additional Comments From tsv at solvo dot ru 2005-05-05 20:03 ---
(In reply to comment #20)
(In reply to comment #19)
Should not be some warning to be generated?
There is a warning if going directly from char * to the union pointer but
since you go through a void
pointer, the
On May 5, 2005, at 4:03 PM, tsv at solvo dot ru wrote:
I am trying to find out where unaligned pointer is came from. Going
couple
functions back I found that it is the address if unsigned char
variable
allocated on stack. Should I look at this issue or it might be
possible in
theory and I
--- Additional Comments From pinskia at physics dot uc dot edu 2005-05-05
20:06 ---
Subject: Re: [4.0/4.1 regression] ivopts produces code that generates
unaligned access exception
On May 5, 2005, at 4:03 PM, tsv at solvo dot ru wrote:
I am trying to find out where unaligned
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
20:12 ---
*** This bug has been marked as a duplicate of 20925 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
20:12 ---
*** Bug 21394 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From andre dot maute at gmx dot de 2005-05-05
20:12 ---
i want to supplement my compile time tests which shows that a regression
was introduced between 2005/03/26 an 2005/04/02
g++-4.0-20050402 -v
Using built-in specs.
Target: i686-pc-linux-gnu
See http://gcc.gnu.org/ml/libstdc++/2005-04/msg00173.html
If you have code like:
std::string b = bee;
std::string c = see;
std::string a = b + c;
Then the string + operator overload will appear in the final ELF image with
GLOBAL WEAK visibility, meaning it can be bound to the wrong version of
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
22:27 ---
I don't know if this is really a vaild bug, as the standard requires the inline
function as the same so it
would be undefined if they are different.
--
--- Additional Comments From gary at intrepid dot com 2005-05-05 22:32
---
I ran into this recently, and also would like to see configure auto-detect the
lack of 32 bit libs.
That failing, perhaps the install documentation at
http://gcc.gnu.org/install/specific.html#x86-64-x-x
can be
--- Additional Comments From mike at navi dot cx 2005-05-05 22:39 ---
I don't understand what you mean. There's definitely a bug here because a
configuration that the docs say should work, causes mysterious crashes due to
mis-binds of symbols. I suspect building with
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
22:40 ---
So here is the story really global templates have aways global visibility in
C++ so this is not a bug in
GCC or binutils. This is a bug in how you think that you can use two different
versions.
--
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-05-05
22:50 ---
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00448.html
--
What|Removed |Added
I'm trying to use gfortran version GNU Fortran 95 (GCC 4.0.0) on
an Opteron system:
Linux nika 2.6.11.7 #1 SMP Wed Apr 13 13:55:17 AKDT 2005 x86_64 GNU/Linux
I'm building NCAR Graphics, which is a large Fortran 77 and C based software
package. This software builds under various versions of
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
23:26 ---
*** This bug has been marked as a duplicate of 15966 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
23:26 ---
*** Bug 18781 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
23:26 ---
*** This bug has been marked as a duplicate of 15966 ***
--
What|Removed |Added
--
Bug 19276 depends on bug 18781, which changed state.
Bug 18781 Summary: [ICE] WRITE with FMT from CHARACTER array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18781
What|Old Value |New Value
--
Bug 18834 depends on bug 18781, which changed state.
Bug 18781 Summary: [ICE] WRITE with FMT from CHARACTER array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18781
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
23:26 ---
*** Bug 21406 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05
23:26 ---
*** Bug 21406 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
Bug 19292 depends on bug 18781, which changed state.
Bug 18781 Summary: [ICE] WRITE with FMT from CHARACTER array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18781
What|Old Value |New Value
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-05
23:30 ---
Subject: Bug 21352
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-05 23:30:27
Modified files:
gcc/cp :
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-05
23:35 ---
This code is not valid (it tries to use a non-static member function, without
taking its address to form a pointer-to-member).
The ICE has been fixed in 4.0.1 and 4.1. This bug will not be fixed in
--- Additional Comments From tbptbp at gmail dot com 2005-05-05 23:58
---
For future reference, i'm including my end-user offline answer to Uros regarding
always_inline usage.
Here we go:
I was trying to take a quick look at your bugreport regarding
always_inline attrubite. Just a
--- Additional Comments From mike at navi dot cx 2005-05-06 00:17 ---
No, there is very definitely a bug here even if it's just in the documentation.
The GCC docs say in very clear and unambiguous terms that this will work, by
design. Not by accident, by design. That's the whole point
The is huge bug which effects a large amount of C++, we should not abort.
extern C void abort(void);
struct T1 {int a, b; virtual void f(){}};
struct T : T1 { struct T1 w; int b; };
void foo (struct T1 *p) { struct T *q = dynamic_castT*(p); if (q-b != 2)
abort (); }
int main () { struct T c; c.b
--
What|Removed |Added
Target Milestone|--- |4.1.0
Version|4.0.0 |4.1.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06
00:25 ---
Oh, I got the idea for this testcase after ssb asked about what the kernel was
doing was valid and his
example code but unlike that code, this is valid as C++ works slightly
different than C.
--
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-05-06 00:27 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED
In GCC's version of pmmintrin.h we have:
#ifdef __SSE3__
#include xmmintrin.h
#include emmintrin.h
/* Additional bits in the MXCSR. */
#define _MM_DENORMALS_ZERO_MASK 0x0040
#define _MM_DENORMALS_ZERO_ON 0x0040
#define _MM_DENORMALS_ZERO_OFF 0x
#define
--
What|Removed |Added
Component|c |target
Keywords||ssemmx
[EMAIL PROTECTED] hcol]$ gfortran -c difq3.F -o difq3.o
In file difq3.F:693
ams(1:ngmax)=
1
Error: The FORALL with index 'j' cause more than one assignment to this object
at (1)
In file difq3.F:696
p2m(1:ngmax)=0.5d0*(3.0d0*ams(1:ngmax)-1d0)
1
Error: The
--- Additional Comments From joe at confucius dot gnacademy dot org
2005-05-06 00:59 ---
Created an attachment (id=8826)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8826action=view)
Sample fortran file which generates error
--
1 - 100 of 110 matches
Mail list logo
