$cat nested_reshape.f90
program nested_reshape
implicit none
real :: k(8,2)
real :: o(8,2)
k =
reshape((/1.0,2.0,3.0,4.0,5.0,6.0,7.0,8.0,9.0,10.0,11.0,12.0,13.0,14.0,15.0,16.0/),
(/8,2/))
o = reshape(reshape(k, (/2,8/), order=(/2,1/)), (/8,2/))
end program
This program compiles fine,
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-12
06:21 ---
Patch in progress.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |l
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-12
06:18 ---
It's xref_tag/push_tag bug.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot
The following test code (derived from the blojsom wiki code) exposes a bug in
our regex compiler
import java.util.regex.Pattern;
public class pat
{
private static final String YMD_PERMALINK_REGEX =
"/(\\d\\d\\d\\d)/(\\d{1,2}+)/(\\d{1,2}+)/(.+)";
private static final Pattern YMD_PERMA
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-03-12 05:11 ---
Fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RES
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-12
04:56 ---
Subject: Bug 20419
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-12 04:56:30
Modified files:
gcc: ChangeLog builtins.c
Log message:
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-12 00:14
---
*** This bug has been marked as a duplicate of 17917 ***
--
What|Removed |Added
S
--
Bug 20405 depends on bug 20146, which changed state.
Bug 20146 Summary: internal compiler error on equivalence
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20146
What|Old Value |New Value
---
--- Additional Comments From tobi at gcc dot gnu dot org 2005-03-12 00:15
---
*** Bug 20146 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From janis at gcc dot gnu dot org 2005-03-11 23:53
---
This is a regression from GCC 3.3. I'm working on a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19985
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-11
23:04 ---
Subject: Bug 20306
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-11 23:03:56
Modified files:
gcc: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-11
22:59 ---
Subject: Bug 20306
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-11 22:58:53
Modified files:
gcc: ChangeLog expr.c
Log message:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
22:55 ---
(In reply to comment #3)
> > > - Why the casts to double?
> > Because that is required by the C standard.
>
> Isn't that covered by the as-if rule? I'm fairly
> sure the cast to double won't change the res
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11
22:49 ---
> > - Why the casts to double?
> Because that is required by the C standard.
Isn't that covered by the as-if rule? I'm fairly
sure the cast to double won't change the result of
the "<" operator :-)
--
--- Additional Comments From pinskia at physics dot uc dot edu 2005-03-11
22:41 ---
Subject: Re: pessimization of complex expression
On Mar 11, 2005, at 4:59 PM, Thomas dot Koenig at online dot de wrote:
>
> --- Additional Comments From Thomas dot Koenig at online dot de
> 2005
On Mar 11, 2005, at 4:59 PM, Thomas dot Koenig at online dot de wrote:
--- Additional Comments From Thomas dot Koenig at online dot de
2005-03-11 21:59 ---
There are two strange things here:
- Why the + 0. ?
- Why the casts to double?
Because that is required by the C standard.
-- Pinski
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-03-11 22:33 ---
My vote would be to fix the NIST test suite, which
has invalid code. ;-) Gfortran is doing the right
thing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155
8;
:
foo (&cr, &ci);
return (double) (cr + 0.0) + (double) (ci + 0.0) < 0.0;
}
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1/configure --prefix=/home/ig25
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050311 (experimental)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11
21:59 ---
There are two strange things here:
- Why the + 0. ?
- Why the casts to double?
--
What|Removed |Added
--
--- Additional Comments From david dot moore at intel dot com 2005-03-11
21:39 ---
Oops - this happened when I hit refresh to see Paulo's comments. Instead it
resubmitted the bug! Very strange.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20433
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11
21:36 ---
(In reply to comment #1)
> D.2395 * 0.0
> Can trap if D.2395 is a non quiet NAN.
D.2395 gets its value from
D.2395 = SR.23 / SR.24;
two lines earlier. Is there anything that would generate
a signal
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
21:34 ---
*** Bug 20433 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20431
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
21:34 ---
*** This bug has been marked as a duplicate of 20431 ***
--
What|Removed |Added
Large values (that should produce inf, produce a bogus result instead.
For example, 1.0e+309 produces 1.39065e-309 on gcc 3.4.3!
Here is the trivial program:
#include
#include
using namespace std;
int main()
{
double a,b;
cout << "Enter a (Using cin):";
cin >> a;
printf ("Enter b (
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
21:25 ---
D.2395 * 0.0
Can trap if D.2395 is a non quiet NAN.
Likewise for "D.2387 + 0.0"
Though in this case it does not matter because we are going to trap later on.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11
21:21 ---
My vote would go for "fixing" this, because of the NIST
testsuite failure.
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155
--- Additional Comments From pcarlini at suse dot de 2005-03-11 21:20
---
1.39065e-309 is just a random bit pattern: a is uninitialized. Indeed, the input
of 1.0e+309 fails, a is left untouched and afterwards cin.fail() is true. Ok.
--
What|Removed |A
.2397;
SR.26 = (0.0 - D.2395) / D.2397;
:
return (double) (float) SR.25 + (double) (float) SR.26 < 0.0;
}
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1/configure --prefix=/home/ig25
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050311
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-03-11 21:14 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED
Large values (that should produce inf, produce a bogus result instead.
For example, 1.0e+309 produces 1.39065e-309 on gcc 3.4.3!
Here is the trivial program:
#include
#include
using namespace std;
int main()
{
double a,b;
cout << "Enter a (Using cin):";
cin >> a;
printf ("Enter b (
--- Additional Comments From giovannibajo at libero dot it 2005-03-11
20:42 ---
*** This bug has been marked as a duplicate of 13744 ***
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-03-11
20:42 ---
*** Bug 20428 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From joseph at codesourcery dot com 2005-03-11
20:01 ---
Subject: Re: Mismatch in pointer indirection level should give
specialized warning
On Fri, 11 Mar 2005, pinskia at gcc dot gnu dot org wrote:
> Really in my mind, we should be rejecting this invalid code
--
Bug 19721 depends on bug 20132, which changed state.
Bug 20132 Summary: Pessimization of induction variable and missed hoisting
opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20132
What|Old Value |New Value
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
19:59 ---
Confirmed fixed for me too so closing as such. I think we choose better iv
with the fold patches
installed.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
19:46 ---
Two things, please attach the source next time if it is this big.
Next could you attach the rsap_constants.mod file.
Well rather attach all the sources which are required to reproduce this.
Also give the o
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-11
19:43 ---
(In reply to comment #18)
> IMHO. One of the tricks with the mult and divmod expanders is precisely
> when should we expand them into their component operations. We clearly
> don't want to do it at the ver
--
What|Removed |Added
Component|fortran |middle-end
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show
/Users/ros/RSAP/v6mac > /sw/bin/gfortran -c samover6.f
samover6.f: In function `samover':
samover6.f:625: error: could not split insn
(insn 5754 5753 5755 (set (reg:SI 0 r0 [2328])
(const_int 4288247288 [0xff9975f8])) 313 {*movsi_internal1} (nil)
(nil))
samover6.f:625: internal compiler
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-11
19:29 ---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Mar 11, 2005, Richard Henderson <[EMAIL PROTECTED]> wrote:
> On Tue, Mar 08, 2005 at 05:42:57PM -0300, Alexandre Oliva
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
18:58 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
18:53 ---
Well it changes the loop into:
.L5:
incl%eax
cmpl%eax, %edx
jne .L5
so yes this is free lunch.
--
What|Removed |Added
---
Hi,
S1: Dell Diminsion p4 2.533ghz 2gig ram
Batch
g++ %1.c -o %1.exe -O3 -mtune=pentium4
g++ -dumpversion
S2: Dell xps p3 1.0ghz 256 meg ram
g++ %1.c -o %1.exe -O3 -mtune=pentium3
g++ -dumpversion
The following code gives much faster timings for 20 vs 10.
Is this a free-lunch or
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
18:39 ---
Confirmed, reduced testcase:
struct buggy_i
{
virtual void release() = 0;
~buggy_i();
};
template
buggy_i *test()
{
struct test_t : public buggy_i
{
void release() {delete this;}
--- Additional Comments From pcarlini at suse dot de 2005-03-11 18:27
---
Maybe I can fix this one too...
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20428
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
18:20 ---
Really in my mind, we should be rejecting this invalid code instead of just
warning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20422
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
18:18 ---
This works on the 4.0 branch and the mainline.
--
What|Removed |Added
Keywords|
--- Additional Comments From falk at debian dot org 2005-03-11 18:03
---
(In reply to comment #5)
> warning: passing arg 1 of `mymalloc':
> 'void **' differs in levels of indirection from 'char *'
>
> My suggestion therefore would be to move towards a situation where
> gcc distingu
--- Additional Comments From pbijdens at storagelabs dot com 2005-03-11
17:54 ---
Given that the default mode of the gcc compiler is pedantic, and accepting your
statement that the warning is standard-compliant. Also given that both cases
indeed violate the standard in the same way, I wo
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-11
17:52 ---
Subject: Bug 20415
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-11 17:52:00
Modified files:
gcc: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-11
17:50 ---
Subject: Bug 20415
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-11 17:50:30
Modified files:
gcc: ChangeLog
gcc/config/i386: i
Keyword (?):
ice-on-valid-code
GCC versions tested:
GNU C++ version 3.4.1 (i686-pc-linux-gnu)
compiled by GNU C version 3.3.3 (SuSE Linux).
GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129465
GNU CPP version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) (cpplib) (i386 Linu
--- Additional Comments From micis at gmx dot de 2005-03-11 17:30 ---
I think there a two different situations:
1) in the derived class you define a method with the same name but
different parameters.
This is typically a serious bug in your program which can result in the
exectutio
--- Additional Comments From falk at debian dot org 2005-03-11 17:25
---
(In reply to comment #3)
> Invalid or not, the request for changing the error message in the other case
> still stands for reasons mentioned: It's impossible currently to distinguish
> between the two mentioned case
--- Additional Comments From pbijdens at storagelabs dot com 2005-03-11
17:02 ---
Invalid or not, the request for changing the error message in the other case
still stands for reasons mentioned: It's impossible currently to distinguish
between the two mentioned cases.
Compiler warnings
--
What|Removed |Added
Known to fail||3.4.3
Known to work||3.2.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20427
According to my reading of ISO 14882 section 5.3.4 paragraph 15, arrays
initialized with 'new' and a trailing '()' should be 'default-initialized'.
According to section 8.5 paragraph 5, the definition of 'default-initialized'
for an array is that each entry in the array should be 'zero-initializ
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-11
16:27 ---
The diagnostic is missing due to calling lookup_name_real inside
cp_parser_lookup_name without the LOOKUP_COMPLAIN flag. Too bad
we cannot just add this flag because this will cause duplicate
error message
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-03-11
16:19 ---
Got it.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lerdsuwa at
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-11 15:19
---
Subject: Re: [PR c++/20103] failure to gimplify constructors for addressable
types
On Tue, Mar 08, 2005 at 05:42:57PM -0300, Alexandre Oliva wrote:
> The change to the gimplify.c is needed to avoid having
> gi
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
15:11 ---
Hmm, ICC gives:
t.cc(7): warning #654: overloaded virtual function "Foo::Func" is only
partially overridden in class "Baz"
class Baz: public Foo
^
t.cc(14): error #165: too few arguments in funct
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
14:58 ---
Confirmed, I thought I saw this before.
--
What|Removed |Added
Status|UNCONFIRME
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
14:55 ---
Yes this is invalid, void* is able to convert to/from any pointer freely but
once void** comes into play it
is a different story.
--
What|Removed |Added
---
--- Additional Comments From bangerth at dealii dot org 2005-03-11 14:50
---
Confirmed, with all gcc versions I have on my system. Here's what icc says:
g/x> icc -Xc -ansi -c x.cc
x.cc(15): error: "E" has already been declared in the current scope
enum E {};
^
x
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-11
14:29 ---
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Mar 10, 2005, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> + ??? Should this should search new for new volatile MEMs and reje
--- Additional Comments From pluto at pld-linux dot org 2005-03-11 14:19
---
(In reply to comment #2)
> Note in C++ they will be constants though but not in C. C has different rules
for constant expressions
> than C++.
Thanks for explain. I have one more basic question.
Why the non-st
--
What|Removed |Added
Summary|ICE in gen_lowpart_general, |[4.1 Regression] ICE in
|at rtlhooks.c:58|gen_lowpart_general, at
--
Bug 19292 depends on bug 20124, which changed state.
Bug 20124 Summary: gfortran prints -.01 incorrectly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20124
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
14:16 ---
Fixed, thanks for your report.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-11
14:06 ---
Note in C++ they will be constants though but not in C. C has different rules
for constant expressions
than C++.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20426
--- Additional Comments From uros at kss-loka dot si 2005-03-11 14:01
---
Just FYI: arith-3.c still fails for me on pentium4. The sistem is fairly
unpatched Red Hat Linux release 8.0 (Psyche):
Linux moron 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux
Compiler versio
--- Additional Comments From falk at debian dot org 2005-03-11 13:28
---
(In reply to comment #0)
> # test.c
> static const unsigned major = 0;
> static const unsigned minor = 9;
> static const unsigned build = 1;
> const unsigned version = (major << 24) | (minor << 16) | build;
>
> # g
# test.c
static const unsigned major = 0;
static const unsigned minor = 9;
static const unsigned build = 1;
const unsigned version = (major << 24) | (minor << 16) | build;
# gcc -c test.c
test.c:4: error: initializer element is not constant
Hmm, which initializer isn't constant? Do I missed somet
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-11
13:07 ---
Subject: Bug 19345
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-rhl-branch
Changes by: [EMAIL PROTECTED] 2005-03-11 13:07:00
Modified files:
gcc: Ch
-print-search-dirs ignores the current multi-os/multilib settings. Thus "gcc
-m64 -print-search-dirs" on powerpc-linux or "gcc -print-search-dirs" on
x86-64-linux prints the wrong library directories. libtool needs this
information to find the libraries in the right directories.
--
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-11 12:45
---
Subject: Re: [PR middle-end/18628] do not fold to label load from tablejump to
reg
On Thu, Mar 10, 2005 at 05:37:48PM -0300, Alexandre Oliva wrote:
> * cse.c (fold_rtx_mem): Don't fold a load from a jump
--- Additional Comments From buytenh at wantstofly dot org 2005-03-11
12:44 ---
Seeing the same bug with gcc 3.4.2 on armv4b when compiling x.org 6.8.1.
This does not happen with gcc 3.3.4.
slicer.cc: In function `void triangulateRect(Arc*, Backend&, int, int, int)':
slicer.cc:382: inte
--- Additional Comments From uros at kss-loka dot si 2005-03-11 12:32
---
The problem is in "*vec_dupv4hi" pattern. However if constraint is changed to
(correct) "TARGET_SSE || TARGET_3DNOW_A", testcase ICES with unrecognizable
insn.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20
--- Additional Comments From jakub at gcc dot gnu dot org 2005-03-11 11:51
---
Just FYI, most distributions ship LinuxThreads headers by default and you
need to specifically ask for NPTL headers ATM. Linking happens against
LinuxThreads libraries as well by default, though NPTL is the d
This does not occur on alpaev67 (but can be reproduced there by printf "echo
alphaev56-unknown-linux-gnu\nexit\n" > config.guess).
[...]
stage1/xgcc -Bstage1/ -B/usr/local/alphaev56-unknown-linux-gnu/bin/ -c -g -O2
-DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pe
--- Additional Comments From falk at debian dot org 2005-03-11 10:36
---
(In reply to comment #0)
> Opinion:
> The default set of warnings for gcc is not sane, and
> eventually causes lower quality code.
The default does not follow "sanity", but it follows the C standard. The
r
I tried the warning option -Woverloaded-virtual in my application
and it was very usefull to me (I managed to find a serious bug).
However, the warning triggers triggers too often.
Consider the following test case:
class Foo
{
public: virtual void Func(int);
virtual void Func(int, int
Change request:
Version:
gcc (GCC) 3.3.5 (Debian 1:3.3.5-8)
Opinion:
The default set of warnings for gcc is not sane, and
eventually causes lower quality code. The incompatible
pointer type warning, when applied to void* checks
is guilty of this.
In my opinion the current
--
What|Removed |Added
OtherBugsDependingO||20421
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12308
All patterns that insert mode switching code via LCM should be marked as
clobbering the flags. fix_trunc* patterns were fixed by PR12308, but
floordf, floorsf, floorxf, ceildf, ceilsf, ceilxf, btruncdf, btruncsf, btruncxf,
nearbyintdf, nearbyintsf and nearbyintxf should still be fixed.
Actually, a
Dear all,
I would like to post a bug report for the GNU C/C++ compiler 3.3-e500.
We use the compiler to generate code for a PowerPC processor.
Used invokation line for the GNU C++ compiler:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple -mn
--- Additional Comments From uros at kss-loka dot si 2005-03-11 09:31
---
Updated patch (no need for FLAGS_REG clobber and some mode macro stuff) at
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01119.html
Regarding comment #4:
I have the same thought as Ferdinand. fisttp insn should not
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-03-11
09:16 ---
Of course it's true - you think I'd lie? ;-)
--
What|Removed |Added
Status|UNCON
);
}
---
fails on following configuration:
Compiler version: 4.1.0 20050311(experimental)
Platform: x86_64-unknown-linux-gnu
configure flags: --prefix=/home/ssb/gcc4
--enable-checking=assert,gc,misc,rtlflag,rtl,tree --disable-werror --e
nable-languages=c,ada,c++,f95,java,objc,treelang
$ ./cc1 bug.c -O1
I will be away from Salt Lake City from
Thursday 03 March 2005
until
Monday 28 March 2005
Your mail regarding "You cannot do that!" will be read when I return.
Because of my very heavy mail volume, responses may be delayed by
weeks, or may prove impossible if your message requ
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-11
08:03 ---
Subject: Bug 20124
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-03-11 08:03:03
Modified files:
libgfortran/io : write.c
libgfortran: Cha
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-11
08:03 ---
Subject: Bug 20124
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-03-11 08:02:46
Modified files:
libgfortran/io : write.
95 matches
Mail list logo
