Hi :
In regmove.c there is function replace_in_call_usage called in
fixup_match_1,
It replaces dst register by src in call_insn, I suspect whether it is necessary
Since comment of CALL_INSN_FUNCTION_USAGE says that no pseudo register
can appear in it and seems src is pseudo register.
further
[redir to gcc-help]
On 01/01/2010 05:44 AM, Andris Kalnozols wrote:
If the bug was a basic programming error, one would expect a
runtime failure (dereferencing a NULL pointer) no matter which
compiler was used.
I would not expect that, and I have no idea whay you would. Undefined
behaviour
I know something is going on with section names, so I thought I'd mention that
there is a big regression on darwin (most -flto -fwhopr -O2 tests fail) at
rev. 155544. An example is:
FAIL: gcc.c-torture/compile/20010313-1.c -O2 -fwhopr (test for excess errors)
Excess errors:
On Fri, Jan 1, 2010 at 7:07 AM, FX fxcoud...@gmail.com wrote:
I know something is going on with section names, so I thought I'd mention
that there is a big regression on darwin (most -flto -fwhopr -O2 tests
fail) at rev. 155544. An example is:
Really lto should be disabled when targeting
Hi,
I have been playing with the GCC vectorizer and examining assembly code
that is produced for dot products that are not for a fixed number of
elements. (This comes up surprisingly often in scientific codes.) So
far, the generated code is not faster than non-vectorized code, and I
think
Benjamin Redelings I wrote:
Hi,
I have been playing with the GCC vectorizer and examining assembly code
that is produced for dot products that are not for a fixed number of
elements. (This comes up surprisingly often in scientific codes.) So
far, the generated code is not faster than
--- Comment #19 from paolo dot carlini at oracle dot com 2010-01-01 10:14
---
(In reply to comment #18)
It does happen when swapping arrays. I believe that array::swap does have a
strong requirement via 23.2.1 p 10, but have xfailed this for the moment.
In that case we have clearly
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2010-01-01 10:27
---
Can you give us the output of the configure line? It should say somewhere:
checking where to find the target c++... just compiled
checking where to find the target c++ for libstdc++... just compiled
--
--- Comment #20 from paolo dot carlini at oracle dot com 2010-01-01 10:46
---
... I meant, still copy constructor, copy assignment, etc, can't throw ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
--- Comment #21 from paolo dot carlini at oracle dot com 2010-01-01 11:03
---
In the meanwhile, I double checked N3000 for basic_string: any literal type
will be allowed, thus if we want to use this type of framework for C++0x we
have first to make sure that the types conform to the
--- Comment #4 from debian-gcc at lists dot debian dot org 2010-01-01
11:06 ---
the sparc64-linux compiler from the trunk is configured with
--with-pkgversion='Debian 20091228-2'
--with-bugurl='file:///usr/share/doc/gcc-snapshot/README.Bugs'
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2010-01-01 12:21
---
(In reply to comment #3)
GNU C++ (GCC) version 4.5.0 20091206 (experimental)
(x86_64-apple-darwin10.2.0)
Fails.
Works with g++ 20100101 (rev. 155544), on x86_64-apple-darwin10.2.0.
Compiled with: g++ -std=c
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-01-01 12:31
---
What about -fdump-rtl-* and -fdump-ipa-*? They have the same problem.
Note that this still wouldn't get what I would expect when doing
gcc -flto -fdump-tree-all -O2 -o t t.c
as you'd get a t.c.*.optimized tree
--- Comment #13 from paolo dot carlini at oracle dot com 2010-01-01 13:08
---
At this point, I don't think we are going to do anything in the 4_3-branch...
otherwise, please remember to adjust the milestone.
--
paolo dot carlini at oracle dot com changed:
What
--- Comment #14 from paolo dot carlini at oracle dot com 2010-01-01 13:08
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #17 from paolo dot carlini at oracle dot com 2010-01-01 13:09
---
Same here...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
The C frontend disturbs the canonical type hierarchy for
typedef unsigned char uint8_t;
uint8_t foo[1][0];
./cc1 -quiet t.c -O2
t.c:2:1: internal compiler error: in get_alias_set, at alias.c:710
Please submit a full bug report,
with preprocessed source if appropriate.
See
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42570
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-01 13:43 ---
But it's a different bug. PR42570.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41925
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-01 13:49 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-01 13:57 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-01 13:57 ---
Subject: Bug 42559
Author: rguenth
Date: Fri Jan 1 13:56:50 2010
New Revision: 14
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=14
Log:
2010-01-01 Richard Guenther rguent...@suse.de
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-01 14:02 ---
Can you attach the original unreduced testcase? With trunk I get
t.ii:6:109: error: 'guint' has not been declared
t.ii:6:128: error: 'GValue' has not been declared
t.ii:6:143: error: 'GParamSpec' has not been
--- Comment #2 from 3dw4rd at verizon dot net 2010-01-01 15:14 ---
Here is the full output:
MacOSX:~/obj ed$ ../gcc/configure --prefix=/Users/ed/bin --with-gmp=/usr/local
--with-mpfr=/usr/local --with-mpc=/usr/local --enable-decimal-float
--enable-languages=c,c++,fortran,objc,obj-c++
--system type: Openmoko Neo Freerunner w/400/500 MHz Samsung 2442B
Processor/SOC (400 minimum, ARM920T core, ARMv4T)
--options given when GCC was configured/built
Configured with:
/home/shr/shr-testing/tmp/work/armv4t-oe-linux-gnueabi/gcc-4.4.2-r0.1/gcc-4.4.2/configure
--build=x86_64-linux
--- Comment #1 from badcloud56 at yahoo dot com 2010-01-01 15:53 ---
Created an attachment (id=19435)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19435action=view)
*.i filegenerated by adding -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42571
This little program:
#include utility
#include vector
int main()
{
std::pairfloat,std::vectorint p(7.7, {3,7,4,8});
}
results in
internal compiler error: Segmentation fault with pair
--
Summary: internal compiler error: Segmentation fault with pair
Product: gcc
For vector, deque, and string
the new member function shrink_to_fit()
is missing.
--
Summary: shrink_to_fit() missing
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
--- Comment #9 from dominiq at lps dot ens dot fr 2010-01-01 16:05 ---
Confirmed with both -m32 or -m64 on x86_64-apple-darwin10 (revision 155540) and
on powerpc-apple-darwin9 (revision 155525: see
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg00043.html ).
Also fails on
--- Comment #6 from hjl at gcc dot gnu dot org 2010-01-01 16:49 ---
Subject: Bug 42531
Author: hjl
Date: Fri Jan 1 16:49:15 2010
New Revision: 15
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=15
Log:
Remove asterisk in LTO section name.
2010-01-01 H.J. Lu
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-01-01
16:51 ---
Created an attachment (id=19436)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19436action=view)
Output of -v
Does not work for me without --with-arch / --with-tune.
--
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-01 17:08
---
Yeah, *a lot* of C++0x things are missing, or still incorrectly implemented, in
general we are not tracking in Bugzilla each!
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-01 17:09 ---
I can't make sens of
/* If primop0 was sign-extended and unsigned comparison specd,
we did a signed comparison above using the signed type bounds.
But the comparison we output must be
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-01 17:15
---
Current release branch and mainline give:
.../stl_pair.h:88: warning: in call to std::pair_T1, _T2::pair(_U1,
_U2) [with _U1 = double, _U2 = std::initializer_listint, _T1 = float, _T2 =
std::vectorint,
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-01 17:16 ---
It looks like the linker plugin doesn't get the -march command line flag
passed. It works for me without -fuse-linker-plugin.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-01 17:17
---
Oops, the warning message begins like this:
42572.cc: In function int main():
42572.cc:6: warning: deducing _U2 as std::initializer_listint
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42572
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-01 17:19 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-01 17:19 ---
Subject: Bug 42570
Author: rguenth
Date: Fri Jan 1 17:19:02 2010
New Revision: 17
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=17
Log:
2010-01-01 Richard Guenther rguent...@suse.de
PR
The following code (by Alex Vod.)
struct A {
char a[400];
float* c;
};
struct A glob;
void func();
void func1(float*);
int func2(float*, int*);
void func3(float*);
void test(int *p) {
func1(glob.c);
if (func2(glob.c, p)) {
func();
}
func3(glob.c);
}
is compiled by gcc 4.2.1 to 56
Given the following complete source file:
long long longfunc(long long x, long long y)
{
return x * y;
}
Compile with ARM EABI gcc 4.2.1:
% arm-eabi-gcc -c -O2 -save-temps mul64.c
This yields mul64.i:
# 1 mul64.c
# 1 built-in
# 1 command-line
# 1 mul64.c
long long longfunc(long long x,
--- Comment #2 from mikpe at it dot uu dot se 2010-01-01 17:37 ---
Created an attachment (id=19437)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19437action=view)
fix arm eabi default cpu type
Try this patch, from debian. It corrects arm-eabi to choose an
armv4t-compatible
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-01 17:40 ---
GCC 4.2 is no longer maintained, please reproduce with current trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from d dot g dot gorbachev at gmail dot com 2010-01-01
17:52 ---
`-fuse-linker-plugin' is crucial to reproduce this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42520
--- Comment #2 from jsm28 at gcc dot gnu dot org 2010-01-01 18:08 ---
Subject: Bug 41947
Author: jsm28
Date: Fri Jan 1 18:08:17 2010
New Revision: 18
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=18
Log:
libcpp:
PR preprocessor/41947
* expr.c
--- Comment #3 from jsm28 at gcc dot gnu dot org 2010-01-01 18:10 ---
Fixed for 4.5.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-01 18:43 ---
It's a false positive, the difference is
--- t2.gkd 2010-01-01 19:05:33.0 +0100
+++ t2.gk.gkd 2010-01-01 19:05:33.0 +0100
@@ -45,22 +45,22 @@
])# {*movdi_xor_rex64}
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-01 18:55 ---
Completely removing the offending code regresses in diagnostics. I'll try
removing the code that doesn't make sense to me, but I fear test coverage is
low in this area.
--
Hello,
first of all, I've tried hard to judge if MICO[1] code is wrong or GCC is wrong
in this case, but I still think GCC is wrong here, hence reporting this. I'm
not able to simplify testcase for this, but we're using following idiom:
#include iostream
#include cassert
using namespace std;
--- Comment #1 from kgardas at objectsecurity dot com 2010-01-01 19:20
---
Created an attachment (id=19438)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19438action=view)
MICO's head preprocessed typecode.cc file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42576
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-01-01 19:21 ---
If tckind is really an enum, then the behavior of gcc is correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42576
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-01 19:23 ---
And it is. ((int)0x) is ouside the range of the enum is gcc's behavior
is correct.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from badcloud56 at yahoo dot com 2010-01-01 19:32 ---
(In reply to comment #2)
Created an attachment (id=19437)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19437action=view) [edit]
fix arm eabi default cpu type
Try this patch, from debian. It corrects arm-eabi
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-01 19:43 ---
new TypeCode(TK_RECURSIVE); is undefined and TK_RECURSIVE will
be truncated to fit the enum. That might be the issue that actually
breaks this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42576
--- Comment #4 from mikpe at it dot uu dot se 2010-01-01 19:48 ---
(In reply to comment #3)
Try this patch, from debian. It corrects arm-eabi to choose an
armv4t-compatible arm9tdmi as the default cpu type. Otherwise it may generate
armv5t code, which is consistent with your illegal
--- Comment #5 from badcloud56 at yahoo dot com 2010-01-01 19:57 ---
(In reply to comment #4)
(In reply to comment #3)
Try this patch, from debian. It corrects arm-eabi to choose an
armv4t-compatible arm9tdmi as the default cpu type. Otherwise it may
generate
armv5t code,
--- Comment #1 from steven at gcc dot gnu dot org 2010-01-01 20:16 ---
Probably doesn't work in CSE because -fcse-skip-blocks was removed (for good
reason). You should try to find out why gcse.c doesn't eliminate this. There
could be (should have been?) a REG_EQUAL note to take care of
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-01-01 20:22 ---
Subject: Bug 42455
Author: rguenth
Date: Fri Jan 1 20:22:17 2010
New Revision: 19
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=19
Log:
2010-01-01 Richard Guenther rguent...@suse.de
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-01 20:22 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from steven at gcc dot gnu dot org 2010-01-01 20:25 ---
IMHO this ought to be fixed before gcc 4.5 is released. Diego, agree?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from kgardas at objectsecurity dot com 2010-01-01 20:34
---
yes, tckind is enum. Thanks for pointing out that this is MICO code issue. If
you also could be so kind and cite some C++/C language specification point
which GCC follows here and which all older GCC releases
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|4.5 regression: 16-byte |[4.5 Regression] 16-byte
|aligned double is
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.3 4.4.2 4.5.0
Known to work|
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.3.6 |4.3.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-01 20:39 ---
I would say that at -Os we don't run RTL PRE?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574
--- Comment #3 from steven at gcc dot gnu dot org 2010-01-01 20:44 ---
CPROP should handle this, since the address is a constant if a proper
REG_EQUAL note is placed on the (set (reg) (address)).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574
--- Comment #4 from steven at gcc dot gnu dot org 2010-01-01 21:00 ---
Actually, no - you're right, this is not something CPROP would handle.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574
when building ScummVM (http://scummvm.org) using GCC 4.4.1 on Ubuntu
9.10/amd64:
m...@ghuang-desktop:~/src/scummvm$ g++-4.4
-Wp,-MMD,engines/saga/.deps/animation.d,-MQ,engines/saga/animation.o,-MP
-Wall -Werror -g -ansi -W -Wno-unused-parameter -Wno-empty-body -pedantic
-Wno-long-long
--- Comment #1 from matt at use dot net 2010-01-01 21:02 ---
Created an attachment (id=19439)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19439action=view)
pre-processed output of the file that emitted the warning
commandline:
g++-4.4
--- Comment #2 from matt at use dot net 2010-01-01 21:16 ---
sorry, I lied. This is still an issue in GCC 4.5.20091228.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42577
--- Comment #3 from dirtyepic at gentoo dot org 2010-01-01 22:18 ---
Created an attachment (id=19440)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19440action=view)
gstapev2mux.ii.bz2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42569
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-01 22:42 ---
The array indexing is done with D.25175_104, but
D.25173_102 = (uint16) cutawaySlot_256;
D.25174_103 = D.25173_102 + 10;
D.25175_104 = (int) D.25174_103;
...
if (D.25174_103 9)
goto bb 26;
else
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-01 23:10 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-01-01 23:48 ---
It is caused by revision 155246:
http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00390.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2010-01-02 00:12 ---
Playing with a classic-GCSE pass (resurrected from svn...). No idea yet if it
will help, but nonetheless mine in the mean time.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from steven at gcc dot gnu dot org 2010-01-02 00:21 ---
Re. comment #1: Paulo, which compiler did you use (svn revision number)?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ami_stuff at o2 dot pl 2010-01-02 00:41 ---
The problematic function is as was said ff_rate_estimate_qscale.
I found out which optimizations causes the problem:
-m68020 -m68881 -O1 -fno-tree-ccp -fno-tree-dominator-opts (works ok).
-m68020 -m68881 -O1 (Abort
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-02 00:42 ---
Working with gcc (GCC) 4.5.0 20090808 (experimental) [trunk revision 150579],
I looked at what loop-invariant.c did to the test case.
This is the t.c.154r.loop2 RTL dump (obtained with -fdump-rtl-all-slim):
;;
--- Comment #12 from ami_stuff at o2 dot pl 2010-01-02 00:47 ---
Created an attachment (id=19441)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19441action=view)
files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41311
--- Comment #7 from steven at gcc dot gnu dot org 2010-01-02 00:49 ---
With GCC: (GNU) 4.5.0 20090808 (experimental) [trunk revision 150579] I get:
.arch armv5te
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
--- Comment #5 from steven at gcc dot gnu dot org 2010-01-02 00:52 ---
From GCC: (GNU) 4.5.0 20090808 (experimental) [trunk revision 150579]:
1 @
1 bl
1 pop
1 push
1 sub
2 cmp
2 str
4 add
4 mov
7 ldr
test:
push
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-02 00:57 ---
On x86 -O2:
1 call
1 leal
1 ret
1 subl
2 cmpl
2 testl
2 xorl
3 addl
4 popl
4 pushl
20 movl
test:
pushl %ebp
movl%esp, %ebp
--- Comment #18 from steven at gcc dot gnu dot org 2010-01-02 01:00 ---
Re. comment #17: Any plans to finish this for GCC 4.6 stage 1?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-02 01:05 ---
Comment #3 and comment #5 still true with GCC: (GNU) 4.5.0 20090808
(experimental) [trunk revision 150579] - reconfirmed.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #15 from hjl dot tools at gmail dot com 2010-01-02 01:14
---
Created an attachment (id=19442)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19442action=view)
A patch
lto-wrapper translates
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
--- Comment #16 from hjl dot tools at gmail dot com 2010-01-02 01:25
---
Created an attachment (id=19443)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19443action=view)
A patch to fix a typo
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #7 from mckelvey at maskull dot com 2010-01-02 01:27 ---
OK I do not know this code. But it looks to me like it never even looks at the
source file. It fails because do_spec doesn't seem to find anything to do.
(gdb) print spec
$12 = 0x427e24 %{E|M|MM:%(trad_capable_cpp)
--- Comment #3 from miltoncsl at yahoo dot com 2010-01-02 02:51 ---
I quoted the compilation of the binutils because it is part of the process for
the construction of gcc. From your indication of version 2.16.1, I knew that
this was the last that supported the coff format. I used the
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-02 03:06
---
I'm working on this, and I want to make sure we agree about the third case. As
I understand the Standard, the expected is 1, not -1, that is, I don't see
anything wrong with parsing Pndedelnik as Pnd followed
--- Comment #6 from urbanjost at comcast dot net 2010-01-02 07:50 ---
Subject: Re: BLOCKDATA referenced in EXTERNAL not loading from library
I am using Vista. I reinstalled. No luck.
I updated CygWin 1.7 again and did a reinstall on the developer package
and the base package; got
89 matches
Mail list logo