--- Additional Comments From marcus at jet dot franken dot de 2005-05-10
06:31 ---
see comment #1 ...
you already derefenced the pointer in ppv (in the line
unsigned long lv = *lvp;
)
so the compiler assumes that anohter NULL ptr check is not needed.
--
http://gcc.gnu.or
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10
06:27 ---
Honestly, I would have loved to have fixed this in 3.4.4, but I'm out of time.
I took a quick try at it, but there were lots of patch rejects. It's certainly
doable, but I'm not going to get there. So ..
--- Additional Comments From Tobias dot Kranz at bka dot bund dot de
2005-05-10 06:24 ---
Created an attachment (id=8850)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8850&action=view)
bzip2-packed default.i-File
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21482
Compiling the following code with
/home/veksler/gcc-4.0.0/bin/g++ -Wall -O2 -c bug.cpp
(Works fine with -O0 or with gcc-3.4.3)
Gives:
bug.cpp: In function 'bool foo(bar*, bar*)':
bug.cpp:19: warning: control may reach end of non-void function 'bool
bar_less::operator()(bar*, bar*)' being in
uname:
Linux bkainline 2.6.11.8 #1 SMP Mon May 9 14:12:51 CEST 2005 i686 i686 i386
GNU/Linux
gcc-cmd-line:
if gcc -DDEFAULT_BASEDIR=\"/usr\" -DDATADIR="\"/var/mysql\""
-DDEFAULT_CHARSET_HOME="\"/usr\"" -DSHAREDIR="\"/usr/lib/mysql/data/mysql\""
-DHAVE_CONFIG_H -I. -I. -I.. -I../include -I.-O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
06:05 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-10
05:55 ---
(In reply to comment #18)
> Fixed in 4.0; will not be fixed in 3.4.x.
Closing as such then.
--
What|Removed |Added
--
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-10 05:47
---
DOM leaves PHI nodes like
# i_5 = PHI <1(0)>;
Then SCEV gives a symbolic initial value like i_5 with the step being 1.
So the information from SCEV is useless here.
With a tcb-like pass ordering (running
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-10 05:37
---
The same patch for PR 21458 would work.
--
What|Removed |Added
AssignedTo|unassigned
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10
03:19 ---
Fixed in 4.0; will not be fixed in 3.4.x.
--
What|Removed |Added
Target Milestone|3.4.4
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10
03:17 ---
Fixed in 4.0; will not be fixed in 3.4.x.
--
What|Removed |Added
Status|ASSIGNE
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10
03:16 ---
Eric --
Never mind; test results aren't looking good. It looks like those comments
about offsetof were there for a reason. I'm still going to try applying the
patch to mainline -- but I don't think there
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10
02:49 ---
The reason that this happens when the type assigned is a class types is that
those types have overloaded operator=. There's always an implicit operator=,
even if one is not declared explicitly, with a "thi
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10
02:16 ---
Subject: Bug 18604
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-10 02:15:43
Modified files:
libstdc++-v3 : Change
--
What|Removed |Added
Target Milestone|3.4.4 |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18604
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10
01:58 ---
Subject: Bug 18604
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-10 01:58:21
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/inclu
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10
01:52 ---
Fixed in 4.0.1; will not be fixed in 3.4.x.
--
What|Removed |Added
Status|NEW
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10
01:51 ---
To the extent this is a bug, it's a failure to comply to a future standard. As
such, it's certainly not release-critical, and it's not even really a
regression. Removed target milestone and regression mar
--- Additional Comments From pcarlini at suse dot de 2005-05-10 01:43
---
Also, it's *incorrect* to call this a "3.4 Regression" because happens only in
debug-mode and debug-mode didn't exist at all before 3.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18604
--- Additional Comments From pcarlini at suse dot de 2005-05-10 01:41
---
Hi Mark. Actually, I think we are going to fix this only in 4_0/mainline. Other,
similar, fixes went only to mainline/4_0 and the patch that goes in 4_0/mainline
has *lots* of rejects in 3_4.
--
http://gcc.gnu
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10
01:39 ---
Fixed in 4.0; will not be fixed in 3.4.x.
--
What|Removed |Added
Status|NEW
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10
01:38 ---
C4x is not a primary or secondary platform; removing target milestone.
--
What|Removed |Added
---
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10
01:36 ---
I saw a lot of recent traffic on this issue.
As we're going to be releasing 3.4.4 soon, please commit any changes to the 3.4
branch ASAP.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18604
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10
01:35 ---
Fixed in 4.0; will not be fixed in 3.4.x.
--
What|Removed |Added
Status|ASSIGNE
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10
01:33 ---
Removing target milestone; 68k is not a primary platform.
--
What|Removed |Added
Target M
--- Additional Comments From bje at gcc dot gnu dot org 2005-05-10 01:24
---
Patch approved by rth and committed.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pcarlini at suse dot de 2005-05-10 01:00
---
Mark, your require-fifo/fork work has fixed this PR in 4_0/mainline and I'm
assigning it to you. Close or 3_4 too?!?
--
What|Removed |Added
-
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-10 00:59
---
Just checked in a patch.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10
00:57 ---
Subject: Bug 21443
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-10 00:57:29
Modified files:
gcc/testsuite : ChangeLog
gcc/testsuite/gcc.
--- Additional Comments From jconner at apple dot com 2005-05-10 00:50
---
Proposed patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00773.html
--
What|Removed |Added
---
--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-10 00:35
---
Created an attachment (id=8848)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8848&action=view)
preprocessed crtstuff.c
Preprocessed data.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21481
Last working build gives
troutmask:sgk[236] ~/work/41/bin/gcc --version
gcc (GCC) 4.1.0 20050425 (experimental)
./xgcc -B./ -B/usr/home/sgk/work/41/amd64-unknown-freebsd6.0/bin/ -isystem
/usr/home/sgk/work/41/amd64-unknown-freebsd6.0/include -isystem
/usr/home/sgk/work/41/amd64-unknown-freebsd6.0
--- Additional Comments From robert dot amodeo at ntlworld dot com
2005-05-10 00:22 ---
Yes, your right.
To be fair to the author Herbert Schildt, he mentions this in table 2.2 on
page 38 of his book.
This is not a bug.
Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21473
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10
00:21 ---
Subject: Bug 21052
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-10 00:21:19
Modified files:
gcc: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10
00:19 ---
Subject: Bug 21052
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-10 00:19:32
Modified files:
gcc: ChangeLog
gcc/doc: e
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-10
00:02 ---
Subject: Bug 16676
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-05-10 00:01:46
Modified files:
gcc: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
23:54 ---
Subject: Bug 21160
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 23:53:52
Modified files:
gcc: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
23:52 ---
Subject: Bug 21160
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-09 23:51:55
Modified files:
gcc: ChangeLog
gcc/doc: i
--- Additional Comments From schlie at comcast dot net 2005-05-09 23:19
---
(In reply to comment #1)
> I don't think this is a bug since conf and ppv cannot be null as you
> deferenced them already
> and would trap on most machines. (there is another bug about this recently
> filed t
$cat reshape_bug.f90
program reshape_bug
implicit none
integer, parameter :: NX = 2
complex :: a(0:NX-1)
a(:) = cmplx(0.0, 0.0)
write(*,*) 'before'
write(*,*) a(:)
a(0:NX-1) = reshape(a(0:NX-1), (/NX/))
write(*,*) 'after'
write(*,*) a(:)
end program reshape_bug
$gfortran-snapshot reshape
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
22:51 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
What|Removed |Added
OtherBugsDependingO||21479
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21305
--
What|Removed |Added
BugsThisDependsOn||21305
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21479
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
22:32 ---
Oh, one more thing, deferencing a null pointer is undefined by the C standard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21479
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
22:31 ---
Do you have a pointer to the mail on that list?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21479
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
22:30 ---
Confirmed, if you did " char bigarray[0x1000] = { };" instead it does the
correct thing but doing {} is
GNU extension.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
22:28 ---
I don't think this is a bug since conf and ppv cannot be null as you deferenced
them already and would
trap on most machines. (there is another bug about this recently filed too).
--
http://gcc.gnu.or
--- Additional Comments From tbptbp at gmail dot com 2005-05-09 22:20
---
Additional note, using -fno-gcse slightly reduce the cruft (this one is my new
pet peeve :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21463
Hi,
avr-gcc seems to occasinally remove compare for ppv in following code. This
changes semantics in the if clause and causes incorrect code execution as ppv
is
not compared first before *ppv compare.
void test(int req, void *conf)
{
void **ppv = (void **) conf;
unsigned long *lvp = (u
--
What|Removed |Added
Keywords||missed-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21478
Large local arrays that are initialized to constant values, gcc uses a static
template and a call to
memcpy. If these arrays are all or mostly zeroes, if we clear the array using
memset and then initialize
the non-zero values inline, it is generally better in two ways:
a) it is faster
b) it re
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
22:05 ---
Subject: Bug 21477
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-09 22:04:53
Modified files:
gcc: ChangeLog
gcc/config/rs6000:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
21:59 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--
What|Removed |Added
GCC build triplet|powerpc64-linux |
GCC host triplet|powerpc64-linux |
GCC target triplet|powerpc64-linux |powerpc64-*-
--- Additional Comments From dje at gcc dot gnu dot org 2005-05-09 21:56
---
This is caused by Geoff's mode macros patch:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00392.html
addsi3 and adddi3 had different operand predicates, but the patch combined the
patterns, using the addsi3 pr
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
21:55 ---
Also on powerpc64-darwin.
--
What|Removed |Added
GCC build triplet|powerpc64-linux
--
What|Removed |Added
Keywords||wrong-code
Summary|adddi3 becomes external |[4.1 Regression] adddi3
|referenc
--- Additional Comments From dje at gcc dot gnu dot org 2005-05-09 21:51
---
confirmed
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever C
The following testcase fails on powerpc64-linux with GCC mainline
starting sometime after 2005-05-05 01:24 UTC:
long a, b;
void
foo ()
{
a = b + 2147483647L;
}
int
main ()
{
foo ();
return 0;
}
elm3b11% /opt/gcc-nightly/mline/bin/gcc -m64 -O0 -g bug.c
/tmp/ccwXjSlP.o(.text+0x28): In f
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
21:39 ---
Could you also send an email to [EMAIL PROTECTED] since this is a bug in the
translation?
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
21:38 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
21:37 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
21:36 ---
Confirmed, the problem here is slightly different from 21462 but closely
related.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
21:34 ---
Actually I take that back.
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
21:34 ---
Confirmed, well the "if (SrcP[x]http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21462
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
21:33 ---
*** Bug 21463 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
21:33 ---
*** This bug has been marked as a duplicate of 21462 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
21:32 ---
Confirmed, the only loop that was optimized was:
for (i = 0; i < VALUES_SIZE; i++)
values[i] = - GFC_INTEGER_4_HUGE;
The agruments to intrinsics really should have restrict on them to get the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
21:23 ---
Reduced testcase:
void *g();
static void *count_and_verify_instructions(int *ninst,const unsigned char *p)
{
if (p == ((void *)0))
return g();
*ninst = 0;
return 0;
}
void f(int);
void *decode_wind
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
21:10 ---
Confirmed. There was a patch posted for this somewhere.
--
What|Removed |Added
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-05-09 20:54 ---
(In reply to comment #4)
> Hmm, I think only the second example is a dup.
well, it is very easy to construct pile of such testcases -- just try to compile
anything with -ffixed-ebp -ffixed-ebx -f
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
20:50 ---
This has been failing since at least 2000-12-31.
--
What|Removed |Added
Status|U
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
20:49 ---
: Search converges between 2003-08-29-trunk (#338) and 2003-08-30-trunk (#339).
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
20:47 ---
: Search converges between 2004-05-11-trunk (#454) and 2004-05-14-trunk (#455).
Again since the tree-ssa was merged in.
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
20:46 ---
: Search converges between 2004-05-11-trunk (#454) and 2004-05-14-trunk (#455).
So failing since the tree-ssa was merged in.
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
20:43 ---
This has been failing since the tree-ssa branch was merged in and on the
tree-ssa since at least
2003-05-30.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21440
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
20:41 ---
Confirmed.
--
What|Removed |Added
CC||pinskia at
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
20:40 ---
(In reply to comment #3)
> This broke after 20041211.
But before 20050225, the branch date.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21454
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
20:40 ---
: Search converges between 2004-07-12-trunk (#484) and 2004-07-13-trunk (#485).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21455
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
20:38 ---
This broke after 20041211.
--
What|Removed |Added
Known to fail|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
20:35 ---
This is a dup of bug 21454.
*** This bug has been marked as a duplicate of 21454 ***
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
20:35 ---
*** Bug 21476 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
Summary|const array doesn't live in |[4.0/4.1 Regression] const
|the rodata section in C++ |array doesn't live in the
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-09
20:33 ---
Fixed in 4.1.
--
What|Removed |Added
Status|NEW |RESOLV
Hi,
in the following small example program, g++ puts the constant data into
the .data section and not into .rodata as it should. It works just fine with
the C frontend. This is a regression from at least 3.3/3.4.
Cheers,
Lars
[EMAIL PROTECTED] rodata]$ cat main.c
const char rodata[] =
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
20:30 ---
Hmm, I think only the second example is a dup.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21469
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-05-09 20:28 ---
*** Bug 21469 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-05-09 20:28 ---
*** This bug has been marked as a duplicate of 16185 ***
--
What|Removed |Added
--- Additional Comments From js at jeannot dot org 2005-05-09 20:21 ---
The bug is still present gcc version 3.4.4 20050506.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21351
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
20:20 ---
Subject: Bug 18655
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-09 20:20:26
Modified files:
gcc: ChangeLog dwarf2out.c
Log message:
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-05-09
20:04 ---
Annother testcase. This one fails at -O2 with gcc 4.1.0 20050507 and 4.0.1
20050430.
This is a regression from 3.4.
typedef unsigned long long uint64_t;
register int *env asm ("ebp");
register long T0 asm (
--- Additional Comments From pcarlini at suse dot de 2005-05-09 20:01
---
Fixed for 4.0.1.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
19:59 ---
Subject: Bug 21238
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-09 19:59:17
Modified files:
libstdc++-v3 : Change
--
What|Removed |Added
Component|tree-optimization |middle-end
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show
--- Additional Comments From janis at gcc dot gnu dot org 2005-05-09 19:32
---
sixtrack works fine for me with "-m64 -O2" with both SPEC's test input and its
ref output, for all of my daily builds since 20050503, while with the addition
of -fmodulo-sched it gets miscompares. lucas is no
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-05-09 17:45 ---
This code:
memory.h:413:
*(POINTER *)Freepointer = memory_ARRAY[Size]->free;
memory_ARRAY[Size]->free = Freepointer;
is invalid, because you are changing object of some type via pointer
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-09
17:44 ---
Subject: Bug 20695
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-09 17:42:56
Modified files:
gcc/doc: invoke.texi
gcc/config/sh :
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
17:26 ---
Actually I don't think it is safe to fold any of these.
--
What|Removed |Added
Comp
The program below gives some expressions which gcc could, but does not, evaluate
to true. E.g. gcc considers &p->a true, even when a is the first element
of the struct (is this a bug?), but does not consider &p->b[3] to be true.
struct foo {int a, b[10];};
int subr(int i, struct foo *p)
{
i
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-09
17:21 ---
It is a bug in the library as it is being passed correctly to it:
_gfortran_ioparm.position = "APPEND";
_gfortran_ioparm.position_len = 6;
--
What|Removed |Added
1 - 100 of 183 matches
Mail list logo
