GCC 3.4.4-2 libg2c vs. lib search path
Hi, yes, I have gcc-g77 installed :-) GCC 3.4.4-2 can't find libg2c.a; look e.g. at gcc -lg2c vs. gcc -lm. The same problem exists for libfrtbegin.a. This looks like a regression from 3.4.4-1. The cygwin package search tells me: 3.4.4-1: usr/lib/gcc/i686-pc-cygwin/3.4.4/libg2c.a 3.4.4-2: usr/lib/gcc/i686-pc-cygwin/libg2c.a But for 3.4.4-2 gcc -print-search-dirs gives libraries: =/usr/lib/gcc/i686-pc-cygwin/3.4.4/: /usr/lib/gcc/i686-pc-cygwin/3.4.4/: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/i686-pc-cygwin/3.4.4/: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../i686-pc-cygwin/3.4.4/: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../: /lib/i686-pc-cygwin/3.4.4/: /lib/: /usr/lib/i686-pc-cygwin/3.4.4/: /usr/lib/ (my line breaks) Could someone have a look at it, please? I can survive now with cd /usr/lib/gcc/i686-pc-cygwin/3.4.4/ ln -s ../libg2c.a ln -s ../libfrtbegin.a but I don't want to make that too public (even more public than cygwin@cygwin.com, that is :-) Cheers, Axel. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Please ignore: GCC 3.4.4-2 libg2c vs. lib search path
If only I could use search properly :-/ Sorry about the noise. Axel. Axel Naumann wrote: Hi, yes, I have gcc-g77 installed :-) GCC 3.4.4-2 can't find libg2c.a; look e.g. at gcc -lg2c vs. gcc -lm. The same problem exists for libfrtbegin.a. This looks like a regression from 3.4.4-1. The cygwin package search tells me: 3.4.4-1: usr/lib/gcc/i686-pc-cygwin/3.4.4/libg2c.a 3.4.4-2: usr/lib/gcc/i686-pc-cygwin/libg2c.a But for 3.4.4-2 gcc -print-search-dirs gives libraries: =/usr/lib/gcc/i686-pc-cygwin/3.4.4/: /usr/lib/gcc/i686-pc-cygwin/3.4.4/: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/i686-pc-cygwin/3.4.4/: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../i686-pc-cygwin/3.4.4/: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../: /lib/i686-pc-cygwin/3.4.4/: /lib/: /usr/lib/i686-pc-cygwin/3.4.4/: /usr/lib/ (my line breaks) Could someone have a look at it, please? I can survive now with cd /usr/lib/gcc/i686-pc-cygwin/3.4.4/ ln -s ../libg2c.a ln -s ../libfrtbegin.a but I don't want to make that too public (even more public than cygwin@cygwin.com, that is :-) Cheers, Axel. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
new vs malloc, -fno-exception - Re: Serious performance problems (malloc related?)
Hi,
here's a little study, allocating / freeing mem in a loop, once with the
C malloc/free, once (-DUSE_CXX_HEAP) using new/delete. It reproduces the
factor ~3 for gcc cygwin.
I've built it with MSVC's cl 7.0, gcc 3.3.3, with and without
-mno-cygwin, using the cygwin-inst snapshot from 20050528, cygwin update
from today, on a P4 1.8GHz, 512MB RAM, XPSP2 Prof.
Result: the user fraction with new is 3 times the user fraction with
malloc. mingw and MSVC show no measurable difference.[1][2]
cl -nologo :
real0m3.094s
user0m0.030s
sys 0m0.016s
g++ -mno-cygwin :
real0m3.733s
user0m0.031s
sys 0m0.000s
g++ :
real0m4.226s
user0m2.358s
sys 0m1.796s
cl -nologo -DUSE_CXX_HEAP:
real0m3.114s
user0m0.015s
sys 0m0.015s
g++ -mno-cygwin -DUSE_CXX_HEAP:
real0m3.811s
user0m0.015s
sys 0m0.015s
g++ -DUSE_CXX_HEAP:
real0m8.779s
user0m7.030s
sys 0m1.671s
To reproduce run make.
NOTE: -fno-exceptions has no measurable impact on the results.
Hope that helps, otherwise just ignore it (well - there no need to say
that on cygwin-ml, I suppose :-)
Axel.
NB: the reason I care is because we see the same performance hit (since
a few months) in the cygwin port of the _open_source_ program ROOT
(root.cern.ch).
[1]: The binary is run twice to make sure that the win cache is in the
same state for all combinations. (Disabling the cache might be of
academical interest. It's not real-world, real-use compatible, though.)
[2]: The sys fraction is considerably higher (O(100)) for gcc compared
with mingw/cl. I realize this is somewhat expected - but the amount is
astonishing to me nevertheless. Anyway - that's for later.
#if USE_CXX_HEAP
#include new
#define malloc(SIZE) new char[SIZE]
#define free(POS) delete[] POS
#else
#include stdlib.h
#endif
int main(int argc, char* argv[]) {
const size_t size=1000;
const long int loop0=10;
const long int loop1=10;
char *ptr[loop1];
int i0=0;
int i1=0;
for(;i0loop0;++i0) {
for(i1=0;i1loop1;++i1)
ptr[i1]=(char*)malloc(size);
for(i1=0;i1loop1;++i1)
free(ptr[i1]);
}
return 0;
}
OUTFILE:=check_cyg_mem.out
all:
rm -f $(OUTFILE)
$(MAKE) builds
USE_CXX_HEAP=-DUSE_CXX_HEAP $(MAKE) builds
cat $(OUTFILE)
builds:
CXX=cl -nologo $(MAKE) run
CXX=g++ -mno-cygwin $(MAKE) run
CXX=g++ $(MAKE) run
run:
@$(CXX) $(USE_CXX_HEAP) check_cyg_mem.cxx -o check_cyg_mem.exe \
./check_cyg_mem.exe \
echo -n $(CXX) $(USE_CXX_HEAP): $(OUTFILE) \
bash -c time ./check_cyg_mem.exe $(OUTFILE) 21
.phony: all builds run
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: vtable issue with cygwin 1.5.5.1? [Was: Re: vtable with snapshot =20031123]
Hi Christopher, I ran into a problem with gcc 3.3.1, cygwin snapshots=20031123 (at least, probably also earlier versions). Like 1.5.5, for instance. This isn't specifically a cygwin snapshot issue. Okay, thanks for finding that out. Can I take this as an ack that it's a cygwin issue? Where do we go from here? I'm willing to help, but I need a pointer. 1) There was no cygwin 1.4*. 2) gcc 3.3.1 was released after cygwin 1.5.x. Right. Okay. Fine. So I remember wrong. Sorry about that. I'm already on the waiting list for a new memory implant. [ To prevent us from getting annoyed here because we're not matching our expectations: I guess what I anticipated as an answer was it's a cygwin issue, we'll let you know when we found the reason, or might be a cygwin one, look into some source pointer and see whether you can find out what's going on, or rtfm / wrong list / any other means of education ] Thanks for looking into this, Christopher! Axel. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
vtable with snapshot =20031123
Hi, I ran into a problem with gcc 3.3.1, cygwin snapshots=20031123 (at least, probably also earlier versions). The binary built from the attached sources (with vtbllib.hpp's INLINE_CTOR defined) coredumps. It seems that the vtable is invalid, probably because a class's vtable is created for each translation unit (it only crashes if the c'tor is inlined; #undef INLINE_CTOR fixes vtbl.exe). This did not happen with earlier versions of cygwin (1.4*); as far as I can remember even gcc 3.3.1 with cygwin 1.4* worked. This is why I believe it's a cygwin problem, not a gcc problem - but I'm really just guessing. Could you tell me if you can reproduce this, and whether it's cygwin or gcc or me? If you need more info on my system please let me know (in general: everything up to date, yesterday's cygwin setup.exe installation except for the cygwin snapshot). Axel. vtbl_inline.tar.gz Description: application/gzip -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cyg 1.5.5-1: fgetpos returns -1 problem
Hi,
I have a problem with glibc's fgetpos on current cygwin. Looking around
I couldn't find a previous posting on it.
Running this test program:
---
#include stdio.h
int main(int argc,char**argv) {
FILE *file = fopen(fo.C,rb); // use any existing file here
FILE *write= tmpfile();
char c = fgetc(file);
fpos_t pos;
fpos_t wpos;
while (c!=EOF) {
c = fgetc(file);
fputc(c,write);
fgetpos(file,pos);
fgetpos(write,wpos);
fprintf(stderr,%d vs %d\n,pos,wpos);
}
fseek(write,0,SEEK_SET);
c = fgetc(write);
while (c!=EOF) {
fprintf(stderr,%c,c);
c = fgetc(write);
fgetpos(write,wpos);
fprintf(stderr,%d\n,wpos);
}
return 0;
}
---
gives
---
[...]
r569
e570
t571
u572
r573
n574
575
0576
;577
578
}579
580
581
582
---
on linux - which is what I'd expect to see. On cygwin 1.5.5-1, gcc
3.3.1-2 not in mingw mode (other relevant packages updated today) the
same code gives
---
[...]
r-1
e-1
t-1
u-1
r-1
n-1
-1
0-1
;-1
-1
}-1
-1
---
Is this different behaviour on linux and cygwin expected? I reverted to
gcc 3.2 to do a regression check, but the problem persists. If someone
points me to how to revert my glibc to an older version I'm happy to add
the results of the regression test.
Any help solving this suprising behaviour is appreciated; if someone
needs more input to reproduce it please let me know.
Best regards, Axel.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
