Compilation performance comparison of GCC 3.4.2 and GCC 4.0.0 (20050301) on MICO sources
Hello, last comparison is here: http://gcc.gnu.org/ml/gcc/2005-01/msg01714.html First of all, who has been this brave man/woman who fixed ir.cc regressions? I would like to thank him/her! :-) Well, the results are excelent and regressions (results worser than 5%) are only those: -O1: static.cc (~9%), except2.cc (~5%), pi_impl.cc (~9%), ir.cc (~7%) and some regressions on very small files: uni_base64.cc (~6%), uni_unicode.cc (~7%), uni_fromuni.cc (~11%), uni_touni.cc (~15%) -O2: static.cc (~15%), except2.cc (~5%), pi_impl.cc (~6%) and again some regeressins on the small files: uni_base64.cc (~7%) Overall, 4.0 is now faster about 37% for -O0, 16% for -O1 and 15% for -O2 than 3.4.2 which is really great progress! Thank you all who are working on making GCC more usable! Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com File342-O0 400-O0 Delta% 342-O1 400-O1 Delta% 342-O2 400-O2 Delta% os-unix.cc 3.983.2 24.38 4.393.5224.72 4.433.89 13.88 dii.cc 11.96 8.1 47.65 13.39 11.76 13.86 16.15 14.92 8.24 typecode.cc 8.777.1323 12.96 13.64 -4.99 31.52 19.36 62.81 any.cc 6.615.3723.09 8.979.16-2.07 12.71 12.17 4.44 codec.cc5.674.5424.89 7.3 6.964.899.119.13 -0.22 buffer.cc 3.212.5824.42 3.432.8719.51 3.532.99 18.06 context.cc 3.382.8 20.71 3.7 3.71-0.27 4.044.14 -2.42 except.cc 4.233.4124.05 4.794.379.615.895.32 10.71 dispatch.cc 4.293.3328.83 4.684.0615.27 4.814.4 9.32 string.cc 3.262.5229.37 3.392.7 25.56 3.3 2.76 19.57 object.cc 4.553.7621.01 5.7 4.9215.85 6.875.73 19.9 address.cc 5.123.7536.53 6.244.5836.24 7.115.25 35.43 ior.cc 11.87.7652.06 13.99 9.9241.03 16.15 11.52 40.19 orb.cc 16.111.25 43.11 24.62 19.17 28.43 36.33 25.21 44.11 boa.cc 8.476.4231.93 11.39 9.9614.36 13.86 12.64 9.65 dsi.cc 9.656.7243.610.99 8.3132.25 11.84 9.53 24.24 transport.cc3.953.0529.51 4.3 3.2731.54.3 3.48 23.56 t..port/tcp.cc 3.873.0526.89 4.233.3426.65 4.273.63 17.63 t..port/udp.cc 3.953.1625 4.363.5323.51 4.523.88 16.49 t..port/unix.cc 3.862.9929.14.143.3822.49 4.183.65 14.52 iop.cc 15.36 10.63 44.521.21 19.81 7.0728.01 26.3 6.5 util.cc 5.824.5926.87.6 6.7113.26 9.858.14 21.01 basic_seq.cc3.623.1216.03 3.843.664.923.763.94 -4.57 fast_array.cc 3.732.9128.18 3.872.9332.08 3.822.99 27.76 ssl.cc 8.695.4260.33 8.725.3363.68.395.52 51.99 fixed.cc3.683 22.67 3.933.5311.33 4.1 4.06 0.99 intercept.cc9.626.6644.44 10.93 8.5 28.59 11.68 10 16.8 codeset.cc 5.734.5 27.33 7.146.824.699.729.02 7.76 queue.cc4.213.2629.14 4.563.5927.02 4.593.86 18.91 static.cc 19.314.69 31.38 23.56 25.9-9.03 28.04 33.13 -15.36 current.cc 8.3 5.2259 8.375.1861.58 8.075.1 58.24 policy_impl.cc 11.97 7.9850 13.06 10.19 28.16 14.76 11.95 23.51 service_info.cc 8.225.2357.17 8.265.1361.01 7.975.15 54.76 ioptypes.cc 9.936.9243.512.03 8.3943.38 12.95 9.47 36.75 ssliop.cc 8.485.3857.62 8.545.2462.98 8.165.12 59.38 value.cc10.65 6.6161.12 11.36 7.6748.11 11.84 8.79 34.7 valuetype.cc9.3 6.1451.47 9.997.3535.92 10.53 8.26 27.48 v..type_impl.cc 11.88 8.4241.09 12.39 10.63 16.56 12.94 12.52 3.35 dynany_impl.cc 10.34 8.3324.13 15.52 16.08 -3.48 22.96 21.42 7.19 policy2.cc 8.515.3858.18 8.575.3959 8.465.58 51.61 tckind.cc 8.265.2258.24 8.295.0265.14 7.985.08 57.09 orb_excepts.cc 8.445.2162 8.555.3260.71 8.275.42 52.58 policy.cc 8.375.3 57.92 8.465.2959.92 8.265.49 50.46 poa.cc 12.25 8.3846.18 14.43 12.16 18.67 16.92 15.42 9.73 poa_base.cc 9.656.5547.33 10.19 7.6433.38 11.03 8.48 30.07 poa_impl.cc 16.512.02 37.27 21.97 20.47 7.3328.77 26.29 9.43
Question w.r.t. `'class Foo' has virtual functions but non-virtual destructor` warning.
Hello,
I would like to ask if the behaviour of GCC 4.0.0 20050301 is correct or
not. I have for example abstract base class like:
class Foo
{
public:
virtual unsigned short
iiop_version() const = 0;
};
and when I compile it, GCC emits warning from subject, although this class
is really abstract and will never be instantiated. It's quite easy to add
virtual dtor there, but I'm reluctant to do so, since IMHO GCC should
check if the class is abstract or not, so I would like to ask if I should
fill a bugreport or correct my code.
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Question w.r.t. `'class Foo' has virtual functions but non-virtual destructor` warning.
On Fri, 4 Mar 2005, Jonathan Wakely wrote:
> On Fri, Mar 04, 2005 at 03:51:42PM +0100, Karel Gardas wrote:
>
> > I would like to ask if the behaviour of GCC 4.0.0 20050301 is correct or
> > not. I have for example abstract base class like:
> >
> > class Foo
> > {
> > public:
> > virtual unsigned short
> > iiop_version() const = 0;
> > };
> >
> > and when I compile it, GCC emits warning from subject, although this class
> > is really abstract and will never be instantiated. It's quite easy to add
> > virtual dtor there, but I'm reluctant to do so, since IMHO GCC should
> > check if the class is abstract or not, so I would like to ask if I should
> > fill a bugreport or correct my code.
>
> If it's an Abstract Base Class and you intend to use it through a
> pointer-to-base (or reference-to-base) then it's important that you add
> a virtual dtor.
>
> Whether it is abstract or not has nothing to do with it - if you will
> ever delete a derived object with a static type of the base class then
> the behaviour is undefined if the base class does not have a virtual
> dtor.
>
> e.g. this is undefined behaviour:
>
> class Base {};
> class Derived : public Base {};
>
> Base* p = new Derived;
> delete p;
Yes, that's undefined, but I just define this class to be able to do:
Foo* f = dynamic_cast(x);
l = f->iiop_version();
there is nothing like delete involved. Anyway, I agree with you that emit
warning about this is probably the right thing to do and so I will fix my
code.
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
OT: How is memory latency important on AMD64 box while compiling large C/C++ sources
Hello, first of all, I'm sorry for off-topic, the question from subject might look silly to you, since natural answer might be "it is very important", but in the light of deciding what and how much memory will I need in AMD64 box, I've got into deciding troubles caused by the fact that I can not test the hardware before purchase myself on my prefered benchmark (C++ (MICO) code compilation) As some of the gcc developers seem to have AMD64 boxes, I would like to ask for help or for sharing some experience here. I'm mainly interested in the differences between T1 and T2 timmings and between memory modules providing 2-2-2-5 and 2-3-3-6 latency. If the difference between let say compiling libstdc++ with the best (2-2-2-5/T1 timming) and worst (2-3-3-6/T2 timming) is lower than few percent, then this is no issue, but if the difference is let say more than 10%, then I would like to "tune" the hardware by using faster modules. Everything depends on how GCC is using cache and how much cache it needs (I'm cosidering 512KB cache CPU here either Winchester or Venice core) and that's the reason why I ask here, since I've not been able so far to search by google for sufficient answer for this question. Thanks for any idea and sorry for off-topic! Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: OT: How is memory latency important on AMD64 box while compiling large C/C++ sources
On Tue, 12 Apr 2005, Karel Gardas wrote: > using cache and how much cache it needs (I'm cosidering 512KB cache CPU > here either Winchester or Venice core) and that's the reason why I ask > here, since I've not been able so far to search by google for sufficient > answer for this question. Also the reason why I'm asking here about this, is this Mike Stump's post: http://gcc.gnu.org/ml/gcc/2005-04/msg00030.html Especially: ``Currently gcc takes a cache miss every 20 instructions, or some ungodly number, and that really saps performance.'' but I don't know if this is just an 1st April fool joke or the reality and if I understand "cache miss" right and if this is L1 or L2 cache miss. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
gcc cache misses [was: Re: OT: How is memory latency important on AMD64 box while compiling large C/C++ sources]
On Tue, 12 Apr 2005, Mike Stump wrote: > On Tuesday, April 12, 2005, at 06:38 AM, Karel Gardas wrote: > > Especially: ``Currently gcc takes a cache miss every 20 instructions, > > or > > some ungodly number, and that really saps performance.'' > > > > but I don't know if this is just an 1st April fool joke > > Nope, no joke. The exact number will vary from machine to machine, and > testcase to testcase, but it is much lower than most workloads. > > > or the reality and if I understand "cache miss" right and if this is > > L1 or L2 cache miss. > > D3 miss as I recall. > > cachegrind can also be used to estimate the number (though, not sure > how accurate it is, possibly not very). I use Shark to actually get > the real number. Perhaps it's possible that cachegrind is wrong or cache misses differ from platform to platform, but I would tell that I get very good numbers for gcc running on x86 platform: ==2634== I refs: 6,930,091,914 ==2634== I1 misses: 21,057,598 ==2634== L2i misses:1,748,958 ==2634== I1 miss rate: 0.30% ==2634== L2i miss rate: 0.2% ==2634== ==2634== D refs: 3,547,549,621 (2,283,456,901 rd + 1,264,092,720 wr) ==2634== D1 misses: 27,091,035 ( 24,245,031 rd + 2,846,004 wr) ==2634== L2d misses:9,560,838 (7,447,877 rd + 2,112,961 wr) ==2634== D1 miss rate: 0.7% ( 1.0% + 0.2% ) ==2634== L2d miss rate: 0.2% ( 0.3% + 0.1% ) ==2634== ==2634== L2 refs: 48,148,633 ( 45,302,629 rd + 2,846,004 wr) ==2634== L2 misses:11,309,796 (9,196,835 rd + 2,112,961 wr) ==2634== L2 miss rate:0.1% ( 0.0% + 0.1% ) --2634-- --2634-- Distinct files: 161 --2634-- Distinct fns: 2988 --2634-- BB lookups: 296865 --2634-- With full debug info: 96% (286724) --2634-- With file/line debug info: 0% (0) --2634-- With fn name debug info: 2% (7538) --2634-- With nodebug info: 0% (2603) --2634-- BBs Retranslated: 0 --2634-- Distinct instrs: 243399 --2634-- TT/TC: 0 tc sectors discarded. --2634--56030 chainings, 0 unchainings. --2634-- translate: new 53466 (817978 -> 7795557; ratio 95:10) --2634--discard 0 (0 -> 0; ratio 0:10). --2634-- dispatch: 140800 jumps (bb entries), of which 229222501 (16%) were unchained. --2634--28161/1069704 major/minor sched events. 540307 tt_fast misses. --2634-- reg-alloc: 398 t-req-spill, 1509791+1072 orig+spill uis, 196410 total-reg-r. --2634--sanity: 28162 cheap, 1127 expensive checks. --2634--ccalls: 243735 C calls, 81% saves+restores avoided (1183722 bytes) --2634--379914 args, avg 0.71 setup instrs each (214802 bytes) --2634--0% clear the stack (731205 bytes) --2634--0 retvals, 100% of reg-reg movs avoided (0 bytes) that's with valgrind 1.9.8 "simulating" AMD64 512KB L2 cache processor: ==2634== Startup, with flags: ==2634==--suppressions=/opt/valgrind/lib/valgrind/default.supp ==2634==--I1=65536,2,64 ==2634==--D1=65536,2,64 ==2634==--L2=524288,8,64 ==2634==-v ==2634== Cache configuration used: ==2634== I1: 65536B, 2-way, 64B lines ==2634== D1: 65536B, 2-way, 64B lines ==2634== L2: 524288B, 8-way, 64B lines The running program is gcc3.4.2 compiling one of MICO demos (i.e. quite a load of C++ headers). Just to be sute that my valgrind is reporting "correct" numbers, I've tested compiling of simple C++ hello world (iostream-based) on real Opteron and the numbers (obtained from valgrind 2.2.0 on FC3) were also quite optimistic (actually here gcc running is 3.3.x): ==4107== I refs: 568,524,260 ==4107== I1 misses: 3,448,484 ==4107== L2i misses: 60,065 ==4107== I1 miss rate:0.60% ==4107== L2i miss rate: 0.1% ==4107== ==4107== D refs: 303,765,394 (187,496,999 rd + 116,268,395 wr) ==4107== D1 misses: 2,397,678 ( 1,937,986 rd + 459,692 wr) ==4107== L2d misses:462,261 (141,702 rd + 320,559 wr) ==4107== D1 miss rate: 0.7% (1.0% + 0.3% ) ==4107== L2d miss rate: 0.1% (0.0% + 0.2% ) ==4107== ==4107== L2 refs: 5,846,162 ( 5,386,470 rd + 459,692 wr) ==4107== L2 misses: 522,326 (201,767 rd + 320,559 wr) ==4107== L2 miss rate: 0.0% (0.0% + 0.2% ) --4107-- --4107-- Distinct files: 1 --4107-- Distinct fns: 221 --4107-- Distinct lines: 221 --4107-- Distinct instrs: 43222 --4107-- BB lookups: 192038 --4107-- With full debug info: 0% (0) --4107-- With file/line debug info: 0% (0) --4107-- With fn name debug info: 9% (18970) --4107-- With nodebug info: 90% (173068) --4107-- BBs Retranslated:
Re: GCC 4.1: Buildable on GHz machines only?
On Wed, 27 Apr 2005, Steven Bosscher wrote: > [*] Does anyone have an idea of how large GCC really is? Using sloccount, 4.0.0 release looks like: Totals grouped by language (dominant language first): ansic: 1076327 (43.81%) ada: 541135 (22.03%) java:276544 (11.26%) cpp: 272101 (11.08%) sh: 222630 (9.06%) asm: 31194 (1.27%) yacc: 14900 (0.61%) exp: 8127 (0.33%) objc: 5919 (0.24%) fortran: 4507 (0.18%) perl: 1954 (0.08%) lex:768 (0.03%) awk:542 (0.02%) lisp:59 (0.00%) sed: 20 (0.00%) Total Physical Source Lines of Code (SLOC)= 2,456,727 Development Effort Estimate, Person-Years (Person-Months) = 725.95 (8,711.36) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 6.55 (78.55) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 110.90 Total Estimated Cost to Develop = $ 98,065,527 (average salary = $56,286/year, overhead = 2.40). Please credit this data as "generated using 'SLOCCount' by David A. Wheeler." Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: GCC 4.1: Buildable on GHz machines only?
On Wed, 27 Apr 2005, Daniel Berlin wrote: > If you want a faster compiler, it's hard work. It means not adding > features because the design isn't a good one, *even if the user would > still find it useful*. People aren't willing to do this. It means lots > and lots of profiling, and taking care of little inefficiencies. All I > ever see people suggest is magic bullets. Daniel, I can not agree with it at all! At least for our C++ code, I've seen compiler speedup from GCC 3.2, which was the most slowest compiler, 3.3 was faster because of better memory heuristics, 3.4 was faster probably because of better parser and 4.0 is faster because of a work of many developers here whom I would like to say Thank You! Imagine that G++ is now faster at least about 50% (at least!), when comparing 3.2 and 4.0.0, not just talking about great 25% speedup between 3.4.x and 4.0.0! Conclusion: people are willing to investigate compiler slowness and even they add new features to the compiler itself. Thank you all for writing GCC! Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: building gcc 4.0.0 on Solaris
On Tue, 10 May 2005, Dimitri Papadopoulos-Orfanos wrote: > > Yeah, in 1991 my 386 featured 4 Mb and I really see no reason why it could > > not > > be used to build libgcj nowadays. ;-) > > Ooops :-) > > These were indeed Gb instead of Mb for those wondering... [have not followed this thread, so sorry if it was already suggested] BTW: Have you tried to also look at what ulimits are set on your system? Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
AMD64: dead-lock issue with gcc-4_0-branch libstdc++ and POSIX write locks.
Hello, in a process of installing new box I've found interesting issue: MICO's IDL compiler dead-locks while compiled with 4.0.x, but not while compiled with 3.4.4 (provided by OS). It is even more interesting, since it dead-locks only when linked against 4.0.x's libstdc++ but not when linked against 3.4.4's libstdc++ -- even if it is compiled by 4.0.x compiler, so this is not miscompilation, but rather some issue in libstdc++ itself. The library changes were done by a matter of changing LD_LIBRARY_PATH. Also the problem is that I don't remember seeing this issue on my old i686 box where I used 4.0.x for development recently. Also this might not be an issue caused by arch change, but caused by libc change: old system provides 2.2.5, but new provides 2.3.2 version. I have also tried to find out if this is the first invocation of pthread_rwlock_wrlock or it is not and it is not, so MICO invokes few pthread_rwlock_wrlock calls before dead-lock happen. The dead-lock itself looks: (gdb) bt #0 0x002a96940f8a in pthread_rwlock_wrlock () from /lib/libpthread.so.0 #1 0x002a95e6933d in MICOMT::RWLock::wrlock (this=0x6e0078) at pthreads.h:382 #2 0x002a95e694ce in AutoWRLock (this=0x7fbfffe880, [EMAIL PROTECTED]) at os-thread.h:241 #3 0x002a95e60f50 in CORBA::ORB::add_invoke (this=0x6dff30, rec=0x6f9350) at orb.cc:2160 The compiler is configured with: silence:~/tmp/mico3/demo/poa/hello-1$ c++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4_0-branch/configure --prefix=/home/karel/usr/local/gcc-4_0-branch-20050514 --enable-shared --enable-threads --enable-languages=c++ --disable-checking --enable-__cxa_atexit --disable-multilib Thread model: posix gcc version 4.0.1 20050514 (prerelease) silence:~/tmp/mico3/demo/poa/hello-1$ The OS is Debian sarge amd64 port, which is pure 64bit port w/o providing 32bit compatibility libraries, hence my usage of --disable-multilib I've tested 4.0.0 release, snapshot from 20050507 and cvs checkout from 20050514 and the issue is presented in every version. Is this already known issue reported somewhere or should I try to debug it a bit more or test something specific for you? Thanks! Karel
Re: AMD64: dead-lock issue with gcc-4_0-branch libstdc++ and POSIX write locks.
Hello, just short follow-up to this thread. I've also tried gcc head (from today) and its libstdc++ is OK, i.e. no dead-lock presented. I've also verified that it is libstdc++ and not libgcc_s. Any idea what's going wrong with GCC 4.0.x's libstdc++? Thanks, Karel
Re: GCC 4.1: Buildable on GHz machines only?
On Mon, 16 May 2005, Steven Bosscher wrote: Just for the record, attached is gcctest's history of the overall memory requirement at -O[0123] for combine.i, insn-attrtab.i, and generate.ii (aka PR8361). Honza's bot has been sending these reports since Septemper 2004, so that's where I started. Is it possible to also add -Os to your tested option set? IMHO this option is quite necessary for embedded developers who seems to complain in this thread. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: GCC 4.1: Buildable on GHz machines only?
On Mon, 16 May 2005, DJ Delorie wrote: We already do that for when checking is enabled, well the GC heuristics are tuned such that it does not change which is why --enable-checking=release is always faster than without it. Right, but it doesn't call ulimit(), so other sources of memory leakage wouldn't be affected. I'm thinking if the gcc driver set a per-process limit of, say, 128M, developers would learn to care about working set performance. I like the idea, but will it really work? While compiling MICO I hardly see mem usage below 128MB on 512MB/1GB RAM boxes, perhaps more on 512MB due to memory usage heuristic(s) -- so I assume setting hard ulimit to 128MB will just result in build process crashing instead of slowdown and swapping, which would man get while using mem=128m as a linux boot param. Or am I completely mistaken? Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: GCC 4.1: Buildable on GHz machines only?
On Mon, 16 May 2005, DJ Delorie wrote: so I assume setting hard ulimit to 128MB will just result in build process crashing instead of slowdown and swapping, We would limit physical ram, not virtual ram. If you do a "man setrlimit", I'm talking about RLIMIT_RSS. The result would be slowing down and swapping, not crashing. But will this really work? For example FreeBSD's manpage says: ``RLIMIT_RSS The maximum size (in bytes) to which a process's resident set size may grow. This imposes a limit on the amount of physical memory to be given to a process; if memory is tight, the system will prefer to take memory from pro- cesses that are exceeding their declared resident set size.'' What I have problem understanding is the last sentence of this paragraph in the light of your claim that it will results in swapping especially when we consider developers' machines with 512MB/1GB RAM, i.e. machines where memory is not "tight". Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: GCC 4.1: Buildable on GHz machines only?
Folks, you all are great brave men hacking on one of the most mission-critical free software piece ever. I'm seeing some of you are more and more frustrated, since this thread is turning into the flame-war. As a long time GCC user, I would like to ask you to calm down a bit if this is possible, please! Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: GCC 4.1: Buildable on GHz machines only?
On Tue, 17 May 2005, Ralf Corsepius wrote: This kind of tone will only discourage contributors. My tone was no different than Ralf's toward me. Well, I admit I had been sarcastic/fatalistic in replying to Steven, primarily, because I am pretty much frustrated about GCC's mainstream developer's position/attitude on embedded targets. Steven's answers perfectly queue-in into a long history of incidents which had lead me to my understanding of "GCC mainstream developers' attitude" on "embedded targets", which I already had described in former postings. Ralf, frustration will not help anybody nor GCC itself. Please look into GCC 3.4 and GCC 4.0 release criteria documents: http://gcc.gnu.org/gcc-3.4/criteria.html http://gcc.gnu.org/gcc-4.0/criteria.html you see that 4.0 added "embedded" platforms like arm-none-elf and mips-none-elf to the primary platforms list. That's IMHO just a sign that SC takes embedded developers seriously. Anyway, if you are not satisfied with this list, what about to suggest to SC to add some other more real embedded platform to this list to at least fix some of the most obvious problems? What platform would you suggest? I think that if you take the discussion into this direction then we can see very good fruits comming from it, at least for some future GCC releases. Thanks and I appreciate your hard work on rtems/gcc platform! Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: GCC 4.1: Buildable on GHz machines only?
On Tue, 17 May 2005, Alexandre Oliva wrote: On May 17, 2005, Karel Gardas <[EMAIL PROTECTED]> wrote: you see that 4.0 added "embedded" platforms like arm-none-elf and mips-none-elf to the primary platforms list. These are only embedded targets. You can't run GCC natively on them, so they don't help embedded hosts in any way. Yes, but Ralf was complaining about embedded cross-compiling development for RTEMS. I have not tried to reply to Peter Barada who complains about GCC inablity to be run on embedded targets directly. Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.
4-unknown-linux-gnu Configured with: ../gcc-main/configure --prefix=/home/karel/usr/local/gcc-main-20050514 --enable-shared --enable-threads --enable-languages=c++ --disable-checking --enable-__cxa_atexit --disable-multilib amd64-unknown-linux-gnu Thread model: posix gcc version 4.1.0 20050514 (experimental) CPU: AMD64 processors, speed 1802.33 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 10 Counted DATA_CACHE_MISSES events (Data cache misses) with a unit mask of 0x00 (No unit mask) count 1000 Counted L1_AND_L2_DTLB_MISSES events (L1 and L2 DTLB misses) with a unit mask of 0x00 (No unit mask) count 1000 Counted L1_DTLB_MISSES_L2_DTLB_HITS events (L1 DTLB misses and L2 DTLB hits) with a unit mask of 0x00 (No unit mask) coun t 1000 CPU_CLK_UNHALT...|DATA_CACHE_MIS...|L1_AND_L2_DTLB...|L1_DTLB_MISSES...| samples| %| samples| %| samples| %| samples| %| 4505282 100.000 2641789 100.000193179 100.000 3666902 100.000 cc1plus CPU: AMD64 processors, speed 1802.33 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 10 Counted DATA_CACHE_MISSES events (Data cache misses) with a unit mask of 0x00 (No unit mask) count 1000 Counted L1_AND_L2_DTLB_MISSES events (L1 and L2 DTLB misses) with a unit mask of 0x00 (No unit mask) count 1000 Counted L1_DTLB_MISSES_L2_DTLB_HITS events (L1 DTLB misses and L2 DTLB hits) with a unit mask of 0x00 (No unit mask) coun t 1000 samples %samples %samples %samples %symbol name 1889074.2302 346968 13.1545 2565213.3726 1046392.8740 comptypes 1555103.4823 86426 3.2766 6713 3.4995 2632787.2311 ggc_alloc_stat 1296182.9025 1492695.6592 6987 3.6424 487011 13.3761 lookup_fnfields_1 1043832.3374 6488 0.2460 169 0.0881 9317 0.2559 record_reg_classes 90854 2.0345 14472 0.5487 264 0.1376 33677 0.9250 dfs_walk_all 90136 2.0184 24639 0.9341 663 0.3456 23587 0.6478 walk_tree 81124 1.8166 6738 0.2555 630.0328 28316 0. find_reloads 78124 1.7494 3998 0.1516 154 0.0803 30305 0.8324 _cpp_lex_direct 57288 1.2828 40331 1.5291 8237 4.2940 98403 2.7027 ht_lookup_with_hash 55880 1.2513 7466 0.2831 100 0.0521 1187 0.0326 _cpp_clean_line 49160 1.1008 59362 2.2506 1748 0.9112 79866 2.1936 lookup_field_1 48784 1.0924 70640 2.6781 2231 1.1630 26856 0.7376 compparms 48030 1.0755 42436 1.6089 9417 4.9092 61766 1.6965 htab_find_slot_with_hash 47940 1.0735 38711 1.4676 2053 1.0702 53454 1.4682 tsubst 47034 1.0532 6084 0.2307 671 0.3498 32065 0.8807 splay_tree_splay_helper 45679 1.0229 7168 0.2718 448 0.2335 21898 0.6014 grokdeclarator 44777 1.0027 18205 0.6902 529 0.2758 13609 0.3738 cp_walk_subtrees 39890 0.8933 65131 2.4693 10764 5.6114 6737 0.1850 push_to_top_level -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.
On Tue, 17 May 2005, Andi Kleen wrote: Karel Gardas <[EMAIL PROTECTED]> writes: I've thought that L1 and L2 DTLB misses are the most important for the overall performance or performance degradation, if not please correct me since this is my first attempt to measure and interpret such data. TLB is just for caching the translations from virtual to physical addresses. Normally the data/instruction cache misses are more important. There are a few TLB intensive workloads too, but they tend to use much more memory than gcc normally does. Thanks for TLB explanation! So I think you should rather use ICACHE_MISSES and DATA_CACHE_REFILLS_FROM_SYSTEM, which measure the "real" L2 caches. OK, will do, although I'm not so sure ICACHE_MISSES means L2 I cache, since DCACHE_MISSES in case of D cache seems to means L1 cache, am I right? And perhaps run a normal instruction profile (CPU_CLK_UNHALTED) in parallel and double check the hot spots displayed by the others match the real time hogs. Note you can use upto three performance counters at the same time. CPU_CLK_UNHALTED was provided in my previous email and the results were povided on its basis, i.e. table sorted by CPU_CLK_UNHALTED column. IIRC oprofile also warned me that maximum number of perf. counters in used is four -- that was after the attempt to throw all cache misses into measurement. :-) Thanks for your corrections/ideas! Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.
n cache misses) with a unit mask of 0x00 (No unit mask) count 1000 Counted DATA_CACHE_REFILLS_FROM_SYSTEM events (Data cache refills from system) with a unit mask of 0x1f (All cache states) count 1000 CPU_CLK_UNHALT...|ICACHE_MISSES:...|DATA_CACHE_REF...| samples| %| samples| %| samples| %| -- 5892854 100.000 3907118 100.000769938 100.000 cc1plus CPU: AMD64 processors, speed 1802.33 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 10 Counted ICACHE_MISSES events (Instruction cache misses) with a unit mask of 0x00 (No unit mask) count 1000 Counted DATA_CACHE_REFILLS_FROM_SYSTEM events (Data cache refills from system) with a unit mask of 0x1f (All cache states ) count 1000 samples %samples %samples %symbol name 2640294.4805 61866 1.5834 119923 15.5757 comptypes 2099623.5630 35886 0.9185 15013 1.9499 lookup_fnfields_1 2049923.4787 87966 2.2514 23110 3.0015 ggc_alloc_stat 1688462.8653 17736 0.4539 1303 0.1692 dfs_walk_all 1247152.1164 5806 0.1486 1771 0.2300 record_reg_classes 1230152.0875 13427 0.3437 7191 0.9340 walk_tree 97145 1.6485 40692 1.0415 1079 0.1401 find_reloads 81300 1.3796 802 0.0205 631 0.0820 _cpp_lex_direct 74550 1.2651 9374 0.2399 3920 0.5091 splay_tree_splay_helper 69103 1.1727 1888 0.0483 31028 4.0299 compparms 67387 1.1435 14429 0.3693 5538 0.7193 lookup_field_1 67245 1.1411 27061 0.6926 21805 2.8320 tsubst 63820 1.0830 25820 0.6608 23317 3.0284 htab_find_slot_with_hash 62961 1.0684 5905 0.1511 18892 2.4537 ht_lookup_with_hash 61731 1.0476 1437743.6798 1811 0.2352 grokdeclarator 61177 1.0382 6439 0.1648 3442 0.4470 cp_walk_subtrees 57836 0.9815 1432 0.0367 138 0.0179 dfs_find_final_overrider_pre 57303 0.9724 335 0.0086 445 0.0578 _cpp_clean_line 50819 0.8624 2938 0.0752 48274 6.2699 push_to_top_level -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.
On Tue, 17 May 2005, Mike Stump wrote: On May 17, 2005, at 3:16 PM, Karel Gardas wrote: 1) the most expensive seems to be comptypes -- at least from data L2 refill point of view (~17%) 2) comptypes is also the most CPU intensive operation since the most of time is spent there I think comptypes can be sped up by canonicalizing types better, and also adding a conservative hash and checking it first. Perhaps, anyway this is box with 1GB RAM. Now, I've just for fun used: 0) compiler params used were: -I../include --param ggc-min-expand=30 --param ggc-min-heapsize=4096 -Wall -D_REENTRANT -D_GNU_SOURCE -DPIC -fPIC -c and the picture at least for 4.1.0 is completely different, see below, which means that for machine with small memory gcc misses L2 cache much more, about 529 CLK per one miss, also the top cache misses provider seems to be GC, second comptypes. Cheers, Karel CPU: AMD64 processors, speed 1802.33 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 10 Counted DATA_CACHE_MISSES events (Data cache misses) with a unit mask of 0x00 (No unit mask) count 1000 Counted ICACHE_MISSES events (Instruction cache misses) with a unit mask of 0x00 (No unit mask) count 1000 Counted DATA_CACHE_REFILLS_FROM_SYSTEM events (Data cache refills from system) with a unit mask of 0x1f (All cache states ) count 1000 CPU_CLK_UNHALT...|DATA_CACHE_MIS...|ICACHE_MISSES:...|DATA_CACHE_REF...| samples| %| samples| %| samples| %| samples| %| 5795921 100.000 3695597 100.000 2946594 100.000 1095111 100.000 cc1plus CPU: AMD64 processors, speed 1802.33 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 10 Counted DATA_CACHE_MISSES events (Data cache misses) with a unit mask of 0x00 (No unit mask) count 1000 Counted ICACHE_MISSES events (Instruction cache misses) with a unit mask of 0x00 (No unit mask) count 1000 Counted DATA_CACHE_REFILLS_FROM_SYSTEM events (Data cache refills from system) with a unit mask of 0x1f (All cache states ) count 1000 samples %samples %samples %samples %symbol name 4428737.6411 2770957.4980 406 0.0138 210537 19.2252 gt_ggc_mx_lang_tree_node 3577146.1718 2973938.0472 341 0.0116 92100 8.4101 ggc_set_mark 2084843.5971 3643119.8580 48844 1.6576 88551 8.0860 comptypes 1762843.0415 96291 2.6056 66753 2.2654 27903 2.5480 ggc_alloc_stat 1580482.7269 1889485.1128 26549 0.9010 13119 1.1980 lookup_fnfields_1 1207912.0841 17681 0.4784 12771 0.4334 1178 0.1076 dfs_walk_all 1019001.7581 8530 0.2308 4541 0.1541 1293 0.1181 record_reg_classes 97854 1.6883 28305 0.7659 9740 0.3306 5843 0.5336 walk_tree 80856 1.3951 6314 0.1709 33168 1.1256 990 0.0904 find_reloads 79626 1.3738 4311 0.1167 743 0.0252 640 0.0584 _cpp_lex_direct 75468 1.3021 64101 1.7345 22 7.5e-04 20321 1.8556 cp_tree_node_structure 60301 1.0404 7343 0.1987 6487 0.2202 2986 0.2727 splay_tree_splay_helper 57714 0.9958 41027 1.1102 4436 0.1505 16364 1.4943 ht_lookup_with_hash 56687 0.9780 7502 0.2030 313 0.0106 422 0.0385 _cpp_clean_line 51682 0.8917 71809 1.9431 1513 0.0513 21801 1.9908 compparms 51528 0.8890 65441 1.7708 10699 0.3631 4356 0.3978 lookup_field_1 51470 0.8880 41211 1.1151 20647 0.7007 17549 1.6025 tsubst 50100 0.8644 43384 1.1739 19750 0.6703 18065 1.6496 htab_find_slot_with_hash 49868 0.8604 91428 2.4740 2472 0.0839 41355 3.7763 push_to_top_level -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: GCC 4.1: Buildable on GHz machines only?
On Mon, 16 May 2005, DJ Delorie wrote: What I have problem understanding is the last sentence of this paragraph in the light of your claim that it will results in swapping especially when we consider developers' machines with 512MB/1GB RAM, i.e. machines where memory is not "tight". Sigh, Linux works the same way. Processes can exceed their HARD ulimit if there happens to be memory available, making RLIMIT_RSS basically useless. Perhaps we can use --param ggc-min-expand=X --param ggc-min-heapsize=Y options? I've tried here: http://gcc.gnu.org/ml/gcc/2005-05/msg00967.html and got some interesting results which might be more similar to the machines with low memory. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.
On Mon, 23 May 2005, Mark Mitchell wrote: Mike Stump wrote: On May 17, 2005, at 3:16 PM, Karel Gardas wrote: 1) the most expensive seems to be comptypes -- at least from data L2 refill point of view (~17%) 2) comptypes is also the most CPU intensive operation since the most of time is spent there I think comptypes can be sped up by canonicalizing types better, and also adding a conservative hash and checking it first. We've researched this in detail. Speeding up comptypes can best be done by calling it less often. One of the primary uses is the template machinery, which works very hard to work out whether it already has an existing specialization. The first step is to insert canonicalizations and other speedups there; that would reduce the number of calls to comptypes dramatically. There are also places in the front end that make redundant calls to comptypes; for example, during declaration processing we sometimes check whether or not two declarations match more than once. The changes you suggest might still be helpful, but I'd prefer to see the bigger algorithms fixed first, as those changes will have secondary benefits beyond comptypes as well. Mark, shall I put some RFE to bugzilla to have it recordered somewhere, or is this already on your company or team TODO list? Thanks! Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: GNU C++ 4.0.1/4.1.0 cache misses on MICO sources.
On Mon, 23 May 2005, Mike Stump wrote: On May 23, 2005, at 12:01 PM, Mark Mitchell wrote: We've researched this in detail. As have I, I also have the timings for template heavy code with the more egregious of the bugs fixed in the compiler-server branch, at that time, they were worth a 10x compile time improvement. If someone wants to pull them out from that branch, I think they are fairly isolated, let me know, and I can point the way. If it is possible, I'm at least interested in testing those bits on my classical "benchmark". Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Please help ...
On Fri, 3 Jun 2005, Prafulla Shukla wrote: Hi, We require gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-20) ^^^ What about to try www.redhat.com ? This e-mail message may contain proprietary, confidential or legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify us immediately at [EMAIL PROTECTED] and delete this mail. Please do not send such addition to the public mailing lists, especially when you expect help provided by people on them. Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Making GCC faster
On Mon, 6 Jun 2005, Sam Lauber wrote: There has been a lot of work recently on making GCC output faster code. But GCC isn't very fast. On my slow 750MHz Linux box (which the PIII in it is now R.I.P), it took a whole night to compile 3.4.3. The memory of your box is probably too small, the CPU is IMHO OK. FYI: IIRC I've been doing 3.4.x builds on my 1GHz PIII + 512MB RAM for around 30 minutes (c/c++) and for around 1.5 hour full build. Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures
Hello, On Tue, 12 Jul 2005, Jonathan Wakely wrote: On Tue, Jul 12, 2005 at 12:20:16PM +0200, Christian Joensson wrote: On 7/12/05, Christian Joensson <[EMAIL PROTECTED]> wrote: On 7/12/05, Eric Botcazou <[EMAIL PROTECTED]> wrote: Joe Buck reports the same problems on SPARC/Solaris: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00633.html According to my testing, the fix is to upgrade to GNU Binutils 2.16 or 2.16.1. you wouldn't happen to know if binutils-2.15.94.0.2.2-2.1 (from fedora core development) would suffice? or anyone else?? or even binutils-2.15.92.0.2-5.1 from fedora core 3 updates? That version works for me on x86_64. The minimum binutils for libstdc++ is now 2.15.90.0.1.1, I don't know about the rest of GCC. does this also apply to other than sparc platforms? I'm cunfused by your note about x86_64, since I'm not able to find any notes about minimal binutils 2.15.90.0.1.1 version required for libstdc++ build on AMD64 linux. Especially: http://gcc.gnu.org/install/specific.html notes more recent binutils version than 2.15 release only in case of *-*-solaris2* configuration. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
libstdc++ required binutils version [was: Re: gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures]
On Tue, 12 Jul 2005, Jonathan Wakely wrote: On Tue, 12 Jul 2005, Jonathan Wakely wrote: On Tue, Jul 12, 2005 at 12:20:16PM +0200, Christian Joensson wrote: On 7/12/05, Christian Joensson <[EMAIL PROTECTED]> wrote: On 7/12/05, Eric Botcazou <[EMAIL PROTECTED]> wrote: Joe Buck reports the same problems on SPARC/Solaris: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00633.html According to my testing, the fix is to upgrade to GNU Binutils 2.16 or 2.16.1. you wouldn't happen to know if binutils-2.15.94.0.2.2-2.1 (from fedora core development) would suffice? or anyone else?? or even binutils-2.15.92.0.2-5.1 from fedora core 3 updates? That version works for me on x86_64. The minimum binutils for libstdc++ is now 2.15.90.0.1.1, I don't know about the rest of GCC. does this also apply to other than sparc platforms? I'm cunfused by your I believe that version applies to x86 linux and x86-64 linux. I don't know about Sparc linux. The only hard fact I can confirm first-hand is that the latest binutils from FC3 updates works for me on x86_64. Interesting! Please have a look at: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00602.html those are test results from 4.0.1 release compiled on debian 3.1/AMD64 (pure64 bit). This debian is using binutils 2.15: silence:~$ as --version GNU assembler 2.15 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-linux'. silence:~$ silence:~$ ld --version GNU ld version 2.15 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. silence:~$ and IMHO testresults look quite good except abi_check, don't they? i.e. do you mean updating binutils will resolve abi_check issue in libstdc++ testsuite? Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
4.0.1 build failure on powerpc64-linux
Hello, I'm trying to build 4.0.1 release on powerpc64-linux, but without success so far, since build fails with: /usr/include/bits/stdio.h:77: undefined reference to `.__overflow' build/errors.o(.text+0x214): In function `warning': ../../gcc-4.0.1/gcc/errors.c:50: undefined reference to `.fprintf' build/errors.o(.text+0x228):../../gcc-4.0.1/gcc/errors.c:51: undefined reference to `.vfprintf' build/errors.o(.text+0x274): In function `warning': /usr/include/bits/stdio.h:77: undefined reference to `.__overflow' build/errors.o(.text+0x2e4): In function `error': ../../gcc-4.0.1/gcc/errors.c:65: undefined reference to `.fprintf' build/errors.o(.text+0x2f8):../../gcc-4.0.1/gcc/errors.c:66: undefined reference to `.vfprintf' build/errors.o(.text+0x358): In function `error': /usr/include/bits/stdio.h:77: undefined reference to `.__overflow' build/errors.o(.text+0x3c4): In function `fatal': ../../gcc-4.0.1/gcc/errors.c:82: undefined reference to `.fprintf' build/errors.o(.text+0x3d8):../../gcc-4.0.1/gcc/errors.c:83: undefined reference to `.vfprintf' build/errors.o(.text+0x408):../../gcc-4.0.1/gcc/errors.c:86: undefined reference to `.exit' build/errors.o(.text+0x414): In function `fatal': /usr/include/bits/stdio.h:77: undefined reference to `.__overflow' ../build-powerpc64-unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)(.text+0x44): In function `xmalloc_set_program_name': ../../../gcc-4.0.1/libiberty/xmalloc.c:106: relocation truncated to fit: R_PPC_REL24 sbrk ../build-powerpc64-unknown-linux-gnu/libiberty/libiberty.a(xmalloc.o)(.text+0x7c): In function `xmalloc_failed': ../../../gcc-4.0.1/libiberty/xmalloc.c:119: relocation truncated to fit: R_PPC_REL24 sbrk make[2]: *** [build/genmodes] Error 1 make[2]: Leaving directory `/tmp/kgardas/obj/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/tmp/kgardas/obj/gcc' make: *** [bootstrap-lean] Error 2 I've configured it with: ../gcc-4.0.1/configure --prefix=$HOME/usr/local/gcc-4.0.1 --enable-shared --enable-threads --enable-languages=c++ --disable-checking --enable-__cxa_atexit and run bootstrap-lean by: time make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap-lean Also, http://gcc.gnu.org/install/specific.html#powerpc-x-linux-gnu notes that binutils 2.15 are required, which seems to be available on this system (Debian 3.1/ppc64): [EMAIL PROTECTED]:/tmp/kgardas/obj$ as --version GNU assembler 2.15 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `powerpc-linux'. [EMAIL PROTECTED]:/tmp/kgardas/obj$ [EMAIL PROTECTED]:/tmp/kgardas/obj$ ld --version GNU ld version 2.15 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. [EMAIL PROTECTED]:/tmp/kgardas/obj$ Any hint how to solve this? Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: 4.0.1 build failure on powerpc64-linux
On Mon, 18 Jul 2005, Janis Johnson wrote: On Mon, Jul 18, 2005 at 12:53:01PM +0200, Karel Gardas wrote: I'm trying to build 4.0.1 release on powerpc64-linux, but without success so far, since build fails with: I've configured it with: ../gcc-4.0.1/configure --prefix=$HOME/usr/local/gcc-4.0.1 --enable-shared --enable-threads --enable-languages=c++ --disable-checking --enable-__cxa_atexit This won't work unless the default compiler and binutils generate 64-bit code by default. I build biarch compilers that default to -m32 with "--build=powerpc64-linux --host=powerpc64-linux --target=powerpc64-linux --with-cpu=default32". Thanks! Adding those options makes a difference and now build succeed! Also, http://gcc.gnu.org/install/specific.html#powerpc-x-linux-gnu notes that binutils 2.15 are required, which seems to be available on this system (Debian 3.1/ppc64): I've been using binutils 2.16, but can't remember specific problems with earlier versions. Have you successfully built earlier versions for this target? No, that's my first attempt on building gcc on linux/power platform. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Help on -Wl option
On Fri, 22 Jul 2005, [EMAIL PROTECTED] wrote: Hello My compilation exited with the message : Please read the documentation for ld's --enable-auto-import for details. WHERE CAN I FIND INFORMATION ON THIS OPTION ?!!! I could find anything on gcc or ld or -Wl related pages. Thanks PS : Sorry for shouting I can't believe it's so difficult to find information on this option. info gcc info ld Is this so difficult? Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Separating c++ parser
On Mon, 12 Sep 2005, Ashwin Bharambe wrote: - disable the stage1,stage2 compilation etc. during the build process? IIRC cross-compilers do not use stage1/2/3 as it is not possible to execute produced target binary on the host platform. And for compiling cross-compiler simple `make' is used. So I would recommend the same instead of `make bootstrap' Cheers, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: interesting anecdote on gcc speed
True! The same applies also to GNU C++ and MICO as a testing base. In fact every compiler from the 3.2, 3.3, 3.4, 4.0 set is faster than previous line. Well, 4.0.x is really fast! Only Intel's C++ and Sun's C++ are faster (comparison made on linux and on solaris) when optimization is switched off, but completely lose the fight when optimization is switched on, this means: gcc generates faster code faster in both cases! Once 4.1 is branched out, I'm ready to do some meassurements, since so far what I've seen 4.1 was a bit (really just a bit) slower than 4.0. So thanks to all GCC developers for excellent work provided! Karel On Thu, 3 Nov 2005, Joe Buck wrote: Many of us worry about the compiler getting slower over time, so I was pleased to see a bit of good news from Planet Debian. Norbert Tretkowski reports on his blog at http://www.inittab.de/blog/2005/11/03#20051103_gcc33vs40 : Comparing gcc 3.3 and 4.0 Kernel 2.6.14 builds fine with gcc 4.0 on alpha, so I switched the build system of the Debian linux-2.6 package from gcc 3.3 to gcc 4.0 on alpha. And it seemed that gcc 4.0 is much faster when building the kernel. I started two new builds using time(1), one with gcc 3.3 and one with gcc 4.0. Using gcc 3.3.6: 56692.17s user 2784.40s system 97% cpu 16:54:01.65 total Using gcc 4.0.2: 39189.33s user 2417.85s system 96% cpu 11:57:52.48 total 5 hours less... and the kernel still works fine. -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Hallo GCC Gurus..
This mailing list is dedicated to GCC development, so please send your email to `gcc-help at gcc dot gnu dot org' mailing list which is a list dedicated to helping GCC users. Cheers, Karel On Fri, 25 Nov 2005, FRANCIS MACHOKA wrote: hallos? I am a linux user and I want to learn how to use GCC and become a master in it. Is it possible for me to get full documentation and tutorials? If they are small enough, can they be posted to me via email? If they are pdf,s can I get links to where I can download them from? Please assist.. __ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Solaris/GCC 3.4.x/4.0.x issue: _GLIBCXX_HAVE_ASINL & others.
Hello, I'm trying to solve small MICO build issue on Solaris/GCC platform. The issue is simple: since GCC 3.4.0 we start to fail compiling code which uses asinl and other functions. The actual issue is that configure (generated by autoconf2.13) detects asinl (and others) function as available, while in fact it is not available on the system (headers/libs), but it is available only in GCC's libstdc++ (as a symbol not as a function defined in header file). So this misdetection of asinl and others then cause MICO build to fail since asinl and others are not defined in header files. I've studied this issue on linux and solaris with GCC 3.4.x and 4.0.1 and found that interestingly _GLIBCXX_HAVE_ASINL is defined when libstdc++ do not provide asinl symbol (function) and it is not defined when it provides it. I have two questions with regarding to this: 1) is this issue GCC's bug to publicly expose asinl/ldexpl/frexpl/fmodl/ceill/floorl/fabsl symbols in its libstdc++? 2) is it reliable to use _GLIBCXX_HAVE_ASINL to detect if asinl is just exposed by libstdc++ and not supported by the target OS? Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Xscale big endian tool-chain (how to build it?)
Hello, I have small issue building arm-elf toolchain for using with eCos OS. So far I have used arm-elf tool chain provided by http://www.gnuarm.com/ (I've used 4.0.1 GCC) and there is no problem with it, but now I would like to prefer building my own. I've checked that source files provided on the http://www.gnuarm.com/ website are exactly matching those of binutils/newlib/gcc releases. I've "patched" gcc by copying their t-arm-elf file to gcc/config/arm/t-arm-elf. I've build the compiler by using the instruction provided on: http://www.gnuarm.com/support.html the problem is that their distributed binaries and what I get from the following their instruction are different. Exactly my problem shows while linking eCos application together when it fails with these messages: silence:~/usr/local/xscale-ecos-default/ixdp425_install/examples$ arm-elf-gcc -Wa,-mfpu=softfpa -msoft-float -finline-limit=7000 -mbig-endian -mcpu=xscale -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-sections -fdata-sections -fno-exceptions -mapcs-frame hello.c -o hello.xg2 -I../include -L../lib -Ttarget.ld -nostdlib /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: ERROR: /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a(_udivsi3.o) uses hardware FP, whereas hello.xg2 uses software FP /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: failed to merge target specific data of file /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a(_udivsi3.o) /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: ERROR: /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a(_umodsi3.o) uses hardware FP, whereas hello.xg2 uses software FP /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: failed to merge target specific data of file /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a(_umodsi3.o) /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: ERROR: /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a(_dvmd_tls.o) uses hardware FP, whereas hello.xg2 uses software FP [] if I understand it correctly, then libgcc.a provided in /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a is build with -mhard-float, while my application with -msoft-float. Question: any idea how to build GCC tool-chain with soft-float's libgcc.a for big-endian Xscale? -- here I assume I'm right with my conclusion above, if this is not the case please correct me. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Xscale big endian tool-chain (how to build it?)
On Tue, 3 Jan 2006, Richard Earnshaw wrote: On Sat, 2005-12-31 at 20:26, Karel Gardas wrote: /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: ERROR: /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a(_dvmd_tls.o) uses hardware FP, whereas hello.xg2 uses software FP [] if I understand it correctly, then libgcc.a provided in /home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a is build with -mhard-float, while my application with -msoft-float. Question: any idea how to build GCC tool-chain with soft-float's libgcc.a for big-endian Xscale? -- here I assume I'm right with my conclusion above, if this is not the case please correct me. You get this error if you try to use -msoft-float with a gcc configuration that already defaults to -msoft-float. This is because the default object files are marked incorrectly in this case. The easiest way to work around it is to not use the -msoft-float option for these configurations. OK, if I understand you well, then I should not use -msoft-float for both: compiling of eCos lib and then for compiling my eCos-based app. The problem is that this is not right way how to workaround this issue. I've checked that I'm not using -msoft-float neither for building eCos lib nor for building eCos-based app. I've saved typescript of `make' so I'm sure build does not use -msoft-float anywhere and the issue is still the same. FYI: Options used for eCos lib build are: -finline-limit=7000 -Wa,-mfpu=softfpa -mbig-endian -mcpu=xscale -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-sections -fdata-sections -fno-exceptions -mapcs-frame and options used to build my app are: -mbig-endian -O2 -g hello.c -o hello.xg -L../lib -nostdlib -Ttarget.ld Anyway, could you be so kind and please have a look at my reply to gcc-help, where I've described my suspicion about this issue? http://gcc.gnu.org/ml/gcc-help/2006-01/msg00015.html http://gcc.gnu.org/ml/gcc-help/2006-01/msg00016.html My major doubts are about the build of soft-float libgcc when -msoft-float is not used at all. Thanks! Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Xscale big endian tool-chain (how to build it?)
On Tue, 3 Jan 2006, Richard Earnshaw wrote: On Tue, 2006-01-03 at 15:38, Karel Gardas wrote: OK, if I understand you well, then I should not use -msoft-float for both: compiling of eCos lib and then for compiling my eCos-based app. The problem is that this is not right way how to workaround this issue. I've checked that I'm not using -msoft-float neither for building eCos lib nor for building eCos-based app. I've saved typescript of `make' so I'm sure build does not use -msoft-float anywhere and the issue is still the same. FYI: Options used for eCos lib build are: -finline-limit=7000 -Wa,-mfpu=softfpa -mbig-endian -mcpu=xscale -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-sections -fdata-sections -fno-exceptions -mapcs-frame Try taking -Wa,-mfpu=softfpa out as well. That will probably have the same adverse effect on the object files generated. OK, I've removed this and got this one now: silence:~/usr/local/xscale-ecos-default/ixdp425_install/examples$ arm-elf-gcc -mbig-endian -O2 -g hello.c -o hello.xg -I../include -L../lib -nostdlib -Ttarget.ld /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: ERROR: /tmp/ccKN8dgp.o uses FPA instructions, whereas hello.xg does not /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: failed to merge target specific data of file /tmp/ccKN8dgp.o /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: ERROR: /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/be/libgcc.a(_udivsi3.o) uses FPA instructions, whereas hello.xg does not Anyway, I've now compared fpu and common libgcc and found that really fpu (which should be hard-float) is different from the common lib in be subdirectory (I'm talking about gcc/be/libgcc.a and gcc/be/fpu/libgcc.a), so my assumption about building hard-float libgcc by default is not true neither. Do you have any idea how to proceed with this? Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Xscale big endian tool-chain (how to build it?)
On Tue, 3 Jan 2006, Richard Earnshaw wrote: First of all, you can't in general just copy in the old version of t-arm-elf into a later version of GCC and expect it to work correctly. Compare the gcc-4.0.x version against the sample one from the website and then uncomment the relevant bits to suit your needs (this is for the multilibs stuff). Just a note. I'm using/building gcc-4.0.1 and I'm using/hacking t-arm-elf from the gcc-4.0.1 release. Anyway, thanks for your kind explanation and advice which I'm going to follow to see if it solves my issue. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: Xscale big endian tool-chain (how to build it?)
On Tue, 3 Jan 2006, Richard Earnshaw wrote: On Tue, 2006-01-03 at 15:52, Karel Gardas wrote: On Tue, 3 Jan 2006, Richard Earnshaw wrote: On Tue, 2006-01-03 at 15:38, Karel Gardas wrote: OK, if I understand you well, then I should not use -msoft-float for both: compiling of eCos lib and then for compiling my eCos-based app. The problem is that this is not right way how to workaround this issue. I've checked that I'm not using -msoft-float neither for building eCos lib nor for building eCos-based app. I've saved typescript of `make' so I'm sure build does not use -msoft-float anywhere and the issue is still the same. FYI: Options used for eCos lib build are: -finline-limit=7000 -Wa,-mfpu=softfpa -mbig-endian -mcpu=xscale -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-sections -fdata-sections -fno-exceptions -mapcs-frame Try taking -Wa,-mfpu=softfpa out as well. That will probably have the same adverse effect on the object files generated. OK, I've removed this and got this one now: silence:~/usr/local/xscale-ecos-default/ixdp425_install/examples$ arm-elf-gcc -mbig-endian -O2 -g hello.c -o hello.xg -I../include -L../lib -nostdlib -Ttarget.ld /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: ERROR: /tmp/ccKN8dgp.o uses FPA instructions, whereas hello.xg does not /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: failed to merge target specific data of file /tmp/ccKN8dgp.o /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/../../../../arm-elf/bin/ld: ERROR: /home/karel/usr/local/arm-elf1/lib/gcc/arm-elf/4.0.1/be/libgcc.a(_udivsi3.o) uses FPA instructions, whereas hello.xg does not Anyway, I've now compared fpu and common libgcc and found that really fpu (which should be hard-float) is different from the common lib in be subdirectory (I'm talking about gcc/be/libgcc.a and gcc/be/fpu/libgcc.a), so my assumption about building hard-float libgcc by default is not true neither. Do you have any idea how to proceed with this? Ug, this would appear to be a bundle of different options plus a build-process that ends up with everything conflicting[1] with itself... ;-( First of all, you can't in general just copy in the old version of t-arm-elf into a later version of GCC and expect it to work correctly. Compare the gcc-4.0.x version against the sample one from the website and then uncomment the relevant bits to suit your needs (this is for the multilibs stuff). You probably won't need everything, but if you closely mimic what's been done before you should have fewer problems. The options are generally grouped, so if you uncomment one option, make sure you uncomment the entire group. Next, I suggest you add --with-cpu=xscale when configuring GCC. You can then drop the -mcpu=xscale when compiling (this should also give you better libraries for your system). However, beware that you libraries will now only run on ARMv5 or later processors. I have tried this with binutils 2.16.1 and gcc 4.0.1, but w/o success. The failure happen during compilation of gcc and it looks like: /tmp/arm-elf-build/obj-gcc/gcc/xgcc -B/tmp/arm-elf-build/obj-gcc/gcc/ -nostdinc -B/tmp/arm-elf-build/obj-gcc/arm-elf/newlib/ -isystem /tmp/arm-elf-build/obj-gcc/arm-elf/newlib/targ-include -isystem /tmp/arm-elf-build/gcc-4.0.1/newlib/libc/include -B/home/karel/usr/local/arm-elf1/arm-elf/bin/ -B/home/karel/usr/local/arm-elf1/arm-elf/lib/ -isystem /home/karel/usr/local/arm-elf1/arm-elf/include -isystem /home/karel/usr/local/arm-elf1/arm-elf/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Dinhibit_libc -fno-inline -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc-4.0.1/gcc -I../../gcc-4.0.1/gcc/. -I../../gcc-4.0.1/gcc/../include -I../../gcc-4.0.1/gcc/../libcpp/include -mhard-float -DL_addsubdf3 -xassembler-with-cpp -c ../../gcc-4.0.1/gcc/config/arm/lib1funcs.asm -o libgcc/fpu/_addsubdf3.o ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S: Assembler messages: ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:454: Error: selected processor does not support `mvfeqd f0,#0.0' ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:476: Error: selected processor does not support `mvfeqd f0,#0.0' ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:530: Error: selected processor does not support `ldfd f0,[sp],#8' make[2]: *** [libgcc/fpu/_addsubdf3.o] Error 1 make[2]: Leaving directory `/tmp/arm-elf-build/obj-gcc/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/tmp/arm-elf-build/obj-gcc/gcc' make: *** [all-gcc] Error 2 First of all, I've thought this is because of my original binutils binaries configured with out --with-cpu=xscale, but even if I add this configure switch and rebuild them, the issue is still the
Re: Xscale big endian tool-chain (how to build it?)
On Tue, 3 Jan 2006, Richard Earnshaw wrote: On Tue, 2006-01-03 at 17:15, Karel Gardas wrote: I have tried this with binutils 2.16.1 and gcc 4.0.1, but w/o success. The failure happen during compilation of gcc and it looks like: /tmp/arm-elf-build/obj-gcc/gcc/xgcc -B/tmp/arm-elf-build/obj-gcc/gcc/ -nostdinc -B/tmp/arm-elf-build/obj-gcc/arm-elf/newlib/ -isystem /tmp/arm-elf-build/obj-gcc/arm-elf/newlib/targ-include -isystem /tmp/arm-elf-build/gcc-4.0.1/newlib/libc/include -B/home/karel/usr/local/arm-elf1/arm-elf/bin/ -B/home/karel/usr/local/arm-elf1/arm-elf/lib/ -isystem /home/karel/usr/local/arm-elf1/arm-elf/include -isystem /home/karel/usr/local/arm-elf1/arm-elf/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -Dinhibit_libc -fno-inline -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc-4.0.1/gcc -I../../gcc-4.0.1/gcc/. -I../../gcc-4.0.1/gcc/../include -I../../gcc-4.0.1/gcc/../libcpp/include -mhard-float -DL_addsubdf3 -xassembler-with-cpp -c ../../gcc-4.0.1/gcc/config/arm/lib1funcs.asm -o libgcc/fpu/_addsubdf3.o ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S: Assembler messages: ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:454: Error: selected processor does not support `mvfeqd f0,#0.0' ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:476: Error: selected processor does not support `mvfeqd f0,#0.0' ../../gcc-4.0.1/gcc/config/arm/ieee754-df.S:530: Error: selected processor does not support `ldfd f0,[sp],#8' make[2]: *** [libgcc/fpu/_addsubdf3.o] Error 1 make[2]: Leaving directory `/tmp/arm-elf-build/obj-gcc/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/tmp/arm-elf-build/obj-gcc/gcc' make: *** [all-gcc] Error 2 First of all, I've thought this is because of my original binutils binaries configured with out --with-cpu=xscale, but even if I add this configure switch and rebuild them, the issue is still the same. Perhaps, my bintutils config is still wrong? But I'm short of ideas what to do now... Thanks! Karel PS: in gcc/config/arm/t-arm-elf I only uncommented those options to get BE build: MULTILIB_OPTIONS += mlittle-endian/mbig-endian MULTILIB_DIRNAMES+= le be MULTILIB_MATCHES += mbig-endian=mbe mlittle-endian=mle MULTILIB_OPTIONS+= mhard-float/msoft-float MULTILIB_DIRNAMES += fpu soft MULTILIB_EXCEPTIONS += *mthumb/*mhard-float* MULTILIB_OPTIONS+= mno-thumb-interwork/mthumb-interwork MULTILIB_DIRNAMES += normal interwork You don't need the hard/soft float variants. Just comment them out (the middle group). And this makes the job! Thank you very much for your help! Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
-x assembler-with-cpp behavior different on different unixes.
Hello,
GHC (Haskell compiler) is using builtin gcc's cpp for its cpp
capability. The problem is a little bit different behaviour on
different platform which I observed. As one of GHC's testcases
completely unrelated to gcc's cpp we use:
{-# LANGUAGE CPP #-}
module T7145b ( A.Applicative(pure) ) where
import qualified Control.Applicative as A
pure :: ()
pure = ()
now, internally GHC calls GCC's cpp on this file with some -Is and
following options (-I removed for brevity):
/usr/bin/gcc -E -undef -traditional '-D__GLASGOW_HASKELL__=709'
'-Dsolaris2_BUILD_OS=1' '-Di386_BUILD_ARCH=1' '-Dsolaris2_HOST_OS=1'
'-Di386_HOST_ARCH=1' -x assembler-with-cpp T7145b.hs -o
/tmp/ghc2662_0/ghc2662_1.hscpp
the problem is that produced code looks:
{-# LANGUAGE CPP #-}
module T7145b ( A.Applicative(pure) ) where
import qualified Control.Applicative as A
pure :: ()
pure = ()
so exact copy of the input file. Now, this is with Solaris 11.1
distributed GNU C 4.5.2. I've tested also 4.6.0, 4.7.1 and 4.8.2 built
by myself on the same platform and all those exhibit the same
behaviour.
Now, if I try the same on Ubuntu 14.04 LTS which provides GNU C 4.8.2,
then I get the expected output which contains
# 1 "T7145b.hs"
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 17 "/usr/include/stdc-predef.h" 3 4
[ empty lines cut]
# 1 "" 2
# 1 "T7145b.hs"
{-# LANGUAGE CPP #-}
module T7145b ( A.Applicative(pure) ) where
import qualified Control.Applicative as A
pure :: ()
pure = ()
Now my question is what exactly is expected behaviour and what not.
I'm mainly interested in this # 1 "7145b.hs" since we need it to get
the source file name right in following GHC emitted warning/error
messages. Is there any way how to enable those CPP marks even on
Solaris? Or is Ubuntu using some distro specific patch to enable this
behaviour and the behaviour itself is deprecated?
Thanks!
Karel
Re: -x assembler-with-cpp behavior different on different unixes.
More information: It looks like gcc driver invokes cc1 with -P option
which switches off linemakers on Solaris. On Linux cc1 is invoked
without -P and so linemakers are presented. The question is why on
Solaris -P is added to the options since I don't use it myself. It's
inserted by gcc itself...
Thanks,
Karel
On Fri, Aug 8, 2014 at 8:47 PM, Karel Gardas wrote:
> Hello,
>
> GHC (Haskell compiler) is using builtin gcc's cpp for its cpp
> capability. The problem is a little bit different behaviour on
> different platform which I observed. As one of GHC's testcases
> completely unrelated to gcc's cpp we use:
>
> {-# LANGUAGE CPP #-}
> module T7145b ( A.Applicative(pure) ) where
>
> import qualified Control.Applicative as A
>
> pure :: ()
> pure = ()
>
>
> now, internally GHC calls GCC's cpp on this file with some -Is and
> following options (-I removed for brevity):
> /usr/bin/gcc -E -undef -traditional '-D__GLASGOW_HASKELL__=709'
> '-Dsolaris2_BUILD_OS=1' '-Di386_BUILD_ARCH=1' '-Dsolaris2_HOST_OS=1'
> '-Di386_HOST_ARCH=1' -x assembler-with-cpp T7145b.hs -o
> /tmp/ghc2662_0/ghc2662_1.hscpp
>
> the problem is that produced code looks:
>
> {-# LANGUAGE CPP #-}
> module T7145b ( A.Applicative(pure) ) where
>
> import qualified Control.Applicative as A
>
> pure :: ()
> pure = ()
>
>
> so exact copy of the input file. Now, this is with Solaris 11.1
> distributed GNU C 4.5.2. I've tested also 4.6.0, 4.7.1 and 4.8.2 built
> by myself on the same platform and all those exhibit the same
> behaviour.
>
> Now, if I try the same on Ubuntu 14.04 LTS which provides GNU C 4.8.2,
> then I get the expected output which contains
>
> # 1 "T7145b.hs"
> # 1 ""
> # 1 "/usr/include/stdc-predef.h" 1 3 4
>
> # 17 "/usr/include/stdc-predef.h" 3 4
> [ empty lines cut]
> # 1 "" 2
> # 1 "T7145b.hs"
> {-# LANGUAGE CPP #-}
> module T7145b ( A.Applicative(pure) ) where
>
> import qualified Control.Applicative as A
>
> pure :: ()
> pure = ()
>
> Now my question is what exactly is expected behaviour and what not.
> I'm mainly interested in this # 1 "7145b.hs" since we need it to get
> the source file name right in following GHC emitted warning/error
> messages. Is there any way how to enable those CPP marks even on
> Solaris? Or is Ubuntu using some distro specific patch to enable this
> behaviour and the behaviour itself is deprecated?
>
> Thanks!
>
> Karel
Re: -x assembler-with-cpp behavior different on different unixes.
Hi Rainer,
On Fri, Aug 8, 2014 at 11:04 PM, Rainer Orth
wrote:
> Hi Karel,
>
>> More information: It looks like gcc driver invokes cc1 with -P option
>> which switches off linemakers on Solaris. On Linux cc1 is invoked
>> without -P and so linemakers are presented. The question is why on
>> Solaris -P is added to the options since I don't use it myself. It's
>> inserted by gcc itself...
>
> you can find this explained in gcc/config/i386/sol2.h (so this
> behaviour is Solaris/x86-specific):
>
> /* Solaris 2/Intel as chokes on #line directives before Solaris 10. */
> #undef CPP_SPEC
> #define CPP_SPEC "%{,assembler-with-cpp:-P} %(cpp_subtarget)"
Thanks a lot for this reference! Hmm, I see I can't do with this
anything since I'd like to use as much as possible Solaris bundled GNU
C.
> With Solaris 9 support gone on mainline, this can be revisited now, but
> this won't change anything for released versions.
What shall I do for this to be at least considered?
> Apart from that, why are you invoking gcc with -x assembler-with-cpp
> when the input is clearly anything but assembler input? You're
> obviously lying to the compiler, and I'd go as far as claiming that you
> get what you deserve: garbage in, garbage out.
>
:-) fair enough, but GHC requires to use some CPP and GNU C's provided
one is very comfortable. Well, at least except on Solaris as you
see...
Thanks a lot for your help!
Karel
profile mode output analysis (call stacks to source code mapping)
Hello, with recent fixes into profile mode I've succeed even using it for MICO[1] on OpenSolaris platform. It seems only compilation to static libraries is supported at the moment, but never mind my server run generates something. As it provides some hints I'd like to more closely analyze I would definitely like to find the place in the source code to which the advices apply. Is there any tool which translates call stacks to humans or is there any documentation/hint how to use generated call stack information to find out appropriate place in the source code? Thanks! Karel [1]: www.mico.org
IA64: short data segment overflowed issue
Hello, I'm using GCC 4.3.2 (debian provided) on IA64 machine and I'm starting to be hit by while building GHC (Haskell compiler) HEAD: /usr/bin/ld: : short data segment overflowed (0x434a58 >= 0x40) /usr/bin/ld: can't relax section: No such file or directory linker messages. In the past (with previous GHC releases) it used -G0 to workaround this issue, but it looks like this does not work anymore. I've also verified that current gcc 4.3.2 (debian), gcc 4.4.4 and gcc 4.5.3 (both gentoo's) are not passing test described in the original bug report back in 2001 here: https://bugzilla.redhat.com/show_bug.cgi?id=33354 The bugreports' test result is: kgar...@babe:/tmp$ ./genstring kgar...@babe:/tmp$ gcc -G0 -c main.c f*.c kgar...@babe:/tmp$ gcc -G0 -o main main.o f*.o /usr/bin/ld: main: short data segment overflowed (0x400080 >= 0x40) /usr/bin/ld: can't relax section: File format not recognized collect2: ld returned 1 exit status kgar...@babe:/tmp$ BTW: This is on GCC Compile Farm IA64 machine. Now my question is: how to solve this issue? Does GCC already support something Intel discusses in 2008 here: http://software.intel.com/en-us/articles/short-data-segment-overflow-error-on-linux-64-on-itaniumr-architecture/ -- i.e. using huge memory model for static data? If so, what is the proper way of using it? I.e. what command-line option should I use? Thanks a lot, Karel
Re: i386-rtems does not build on head
If this help, I'd like to add that I succesfully compiled gcc-4.2-20060128.tar.bz2 for the same configuration. Cheers, Karel On Thu, 2 Feb 2006, Joel Sherrill wrote: This is a breakage in about the past week. I built a native compiler from the same source. Does this look familiar to anyone? -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Compilation performance comparison of GCC 4.0.1 and GCC 4.1.0 20060210 on MICO 2.3.12 sources
Hello, it's been a while since my last comparison of various GCC's compilation performance on MICO sources. A lot happened in GCC development since then and so I'm here with more up-to-date measurements. This time I've used MICO 2.3.12 release sources and again measured time of compilation of orb subdirectory files. I've compared my GCC 4.0.1 release with GCC 4.1.0 20060210 prerelease on AMD64 generating code for this platform. Whole tables are below, but overall results are, that 4.1.0 is slower on all compilations (sums) while using -O0/1/2/3/s optimization levels, actual numbers are: -O0: -4% -O1: -21% -O2: -19% -O3: -19% -Os: -9% since I don't know current GCC policy for considering compilation performance regressions, I'm not able to judge what's regression and not. Anyway, interested developers might look into the tables below and if they need more details ask me to provide more information. Cheers, Karel PS: time is measured in seconds, numbers are provided by -time GCC option. File401-O0 410-O0 Delta% 401-O1 410-O1 Delta% 401-O2 410-O2 Delta% os-unix.cc 1.291.290 1.091.81-66.06 1.15 1.24-7.83 dii.cc 2.873 -4.53 3.6 4.13-14.72 4.08 4.63-13.48 typecode.cc 2.252.37-5.33 4.8 5.42-12.92 5.76 6.4 -11.11 any.cc 1.651.71-3.64 2.522.85-13.1 3.07 3.68-19.87 codec.cc1.411.46-3.55 2.042.1 -2.94 2.5 2.79-11.6 buffer.cc 0.820.820 0.890.93-4.49 0.99 1.03-4.04 context.cc 0.870.870 1.021.12-9.81.11 1.23-10.81 except.cc 1.121.14-1.79 1.461.62-10.96 1.56 1.63-4.49 dispatch.cc 1.271.29-1.57 1.481.66-12.16 1.47 1.74-18.37 string.cc 0.8 0.8 0 0.870.870 0.87 0.92-5.75 object.cc 1.141.19-4.39 1.631.98-21.47 1.88 2.27-20.74 address.cc 1.221.24-1.64 1.591.83-15.09 1.77 2.03-14.69 ior.cc 2.923 -2.74 3.764.32-14.89 4.25 4.81-13.18 orb.cc 3.9 4.28-9.74 7.2711 -51.31 9.17 13.3-45.04 dsi.cc 1.922.02-5.21 1.922.29-19.27 2.25 2.42-7.56 transport.cc1.031.05-1.94 1.011.24-22.77 1.25 1.33-6.4 transport/tcp.cc0.980.980 1.081.12-3.71.16 1.22-5.17 transport/udp.cc1 1.01-1 1.1 1.17-6.36 1.2 1.24-3.33 transport/unix.cc 0.950.97-2.11 1.061.1 -3.77 1.12 1.15-2.68 iop.cc 3.783.87-2.38 6.2 7.5 -20.97 7.8 9.18-17.69 util.cc 1.5 1.55-3.33 2.3 3.26-41.74 2.73 3.84-40.66 basic_seq.cc0.940.98-4.26 0.991.05-6.06 1.05 1.09-3.81 fast_array.cc 0.920.94-2.17 0.950.97-2.11 0.97 0.99-2.06 ssl.cc 2.872.94-2.44 3.664.29-17.21 4.1 4.78-16.59 fixed.cc0.920.93-1.09 1.031.1 -6.81.14 1.19-4.39 intercept.cc2.122.17-2.36 2.462.71-10.16 2.66 2.93-10.15 codeset.cc 2.482.55-2.82 3.2 3.66-14.38 3.69 4.2 -13.82 queue.cc1.041.09-4.81 1.131.23-8.85 1.21 1.29-6.61 static.cc 4.464.68-4.93 6.317.61-20.6 7.35 8.74-18.91 current.cc 1.761.8 -2.27 1.791.83-2.23 1.82 1.84-1.1 policy_impl.cc 2.662.73-2.63 3.073.51-14.33 3.1 3.8 -22.58 service_info.cc 1.761.5412.51.751.79-2.29 1.69 1.79-5.92 ioptypes.cc 2.272.241.322.773.27-18.05 3.03 3.58-18.15 ssliop.cc 1.811.84-1.66 1.821.86-2.21.85 1.86-0.54 value.cc2.232.28-2.24 2.442.71-11.07 2.6 2.9 -11.54 valuetype.cc2.092.12-1.44 2.4 2.6 -8.33 2.57 2.75-7 valuetype_impl.cc 2.7 2.85-5.56 2.993.38-13.04 3.27 3.65-11.62 dynany_impl.cc 2.722.83-4.04 4.976.31-26.96 6.25 7.6 -21.6 policy2.cc 1.811.83-1.11.881.95-3.72 1.91 2 -4.71 tckind.cc 1.741.79-2.87 1.761.78-1.14 1.78 1.8 -1.12 orb_excepts.cc 1.8 1.82-1.11 1.791.89-5.59 1.87
Why is libstdc++ abi_check failing on gcc 4.1.0 on amd64 platform?
Hello, I'm curious why is GCC 4.1.0 release libstdc++'s abi_check failing for me on linux/amd64 platform? I've submited my testsuite results here: http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00224.html Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
GCC 4.1.0 C++ broken for threading on OpenBSD 3.9.
/lib/gcc/i386-unknown-openbsd3.9/4.1.0/libgcc.a(unwind-sjlj.o)(.text+0x38f):/home/karel/build/gcc-4.1.0/gcc/gthr-posix.h:541: undefined reference to `pthread_setspecific' /home/karel/usr/local/lib/gcc/i386-unknown-openbsd3.9/4.1.0/libgcc.a(unwind-sjlj.o)(.text+0x3da): In function `_Unwind_Backtrace': /home/karel/build/gcc-4.1.0/gcc/gthr-posix.h:535: undefined reference to `pthread_getspecific' /home/karel/usr/local/lib/gcc/i386-unknown-openbsd3.9/4.1.0/libgcc.a(unwind-sjlj.o)(.text+0x455): In function `_Unwind_SjLj_Resume_or_Rethrow': /home/karel/build/gcc-4.1.0/gcc/gthr-posix.h:535: undefined reference to `pthread_getspecific' /home/karel/usr/local/lib/gcc/i386-unknown-openbsd3.9/4.1.0/libgcc.a(unwind-sjlj.o)(.text+0x4ba): In function `_Unwind_SjLj_Resume': /home/karel/build/gcc-4.1.0/gcc/gthr-posix.h:535: undefined reference to `pthread_getspecific' /home/karel/usr/local/lib/gcc/i386-unknown-openbsd3.9/4.1.0/libgcc.a(unwind-sjlj.o)(.text+0x521): In function `_Unwind_SjLj_ForcedUnwind': /home/karel/build/gcc-4.1.0/gcc/gthr-posix.h:535: undefined reference to `pthread_getspecific' collect2: ld returned 1 exit status $ -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
GCC-4.2-20060325 build failure on OpenBSD 3.9-current
Hello, I'm trying to build GCC-4.2-20060325 on OpenBSD 3.9-current, but it fails with: echo timestamp > s-gtype /home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/xgcc -B/home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/ -B/home/karel/usr/local/gcc-4.2-20060325/i386-unknown-openbsd3.9/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/karel/build/gcc-4.2-20060325/gcc -I/home/karel/build/gcc-4.2-20060325/gcc/build -I/home/karel/build/gcc-4.2-20060325/gcc/../include -I/home/karel/build/gcc-4.2-20060325/gcc/../libcpp/include -I/home/karel/build/gcc-4.2-20060325/gcc/../libdecnumber -I../libdecnumber -o build/rtl.o /home/karel/build/gcc-4.2-20060325/gcc/rtl.c /home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/xgcc -B/home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/ -B/home/karel/usr/local/gcc-4.2-20060325/i386-unknown-openbsd3.9/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/karel/build/gcc-4.2-20060325/gcc -I/home/karel/build/gcc-4.2-20060325/gcc/build -I/home/karel/build/gcc-4.2-20060325/gcc/../include -I/home/karel/build/gcc-4.2-20060325/gcc/../libcpp/include -I/home/karel/build/gcc-4.2-20060325/gcc/../libdecnumber -I../libdecnumber -o build/read-rtl.o /home/karel/build/gcc-4.2-20060325/gcc/read-rtl.c cc1: warnings being treated as errors /home/karel/build/gcc-4.2-20060325/gcc/read-rtl.c: In function 'join_c_conditions': /home/karel/build/gcc-4.2-20060325/gcc/read-rtl.c:787: warning: missing sentinel in function call gmake[3]: *** [build/read-rtl.o] Error 1 gmake[3]: Leaving directory `/home/karel/build/obj-gcc-4.2-20060325/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/home/karel/build/obj-gcc-4.2-20060325' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/home/karel/build/obj-gcc-4.2-20060325' gmake: *** [bootstrap-lean] Error 2 the compiler used for bootstrap is OpenBSD's gcc3.3.5. GCC 4.2 is configured with: /home/karel/build/gcc-4.2-20060325/configure --prefix=/home/karel/usr/local/gcc-4.2-20060325 --enable-shared --enable-threads --disable-checking --disable-nls --enable-languages=c,c++ and it is build with: gmake CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap-lean If I understand this issue correctly, it seems GCC 4.2 stage1 compiler warns about missing sentinel and because of -Werror bootstrap fails. If this is true, then perhaps the same issue happen also on more supported platforms? (Linux/FreeBSD) If so, then my question is: is this already fixed on trunk? Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: GCC-4.2-20060325 build failure on OpenBSD 3.9-current
Hello, I've checkouted todays sources from trunk and I can confirm that the same failure also happens there. Cheers, Karel On Fri, 31 Mar 2006, Karel Gardas wrote: Hello, I'm trying to build GCC-4.2-20060325 on OpenBSD 3.9-current, but it fails with: echo timestamp > s-gtype /home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/xgcc -B/home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/ -B/home/karel/usr/local/gcc-4.2-20060325/i386-unknown-openbsd3.9/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/karel/build/gcc-4.2-20060325/gcc -I/home/karel/build/gcc-4.2-20060325/gcc/build -I/home/karel/build/gcc-4.2-20060325/gcc/../include -I/home/karel/build/gcc-4.2-20060325/gcc/../libcpp/include -I/home/karel/build/gcc-4.2-20060325/gcc/../libdecnumber -I../libdecnumber -o build/rtl.o /home/karel/build/gcc-4.2-20060325/gcc/rtl.c /home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/xgcc -B/home/karel/build/obj-gcc-4.2-20060325/./prev-gcc/ -B/home/karel/usr/local/gcc-4.2-20060325/i386-unknown-openbsd3.9/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/karel/build/gcc-4.2-20060325/gcc -I/home/karel/build/gcc-4.2-20060325/gcc/build -I/home/karel/build/gcc-4.2-20060325/gcc/../include -I/home/karel/build/gcc-4.2-20060325/gcc/../libcpp/include -I/home/karel/build/gcc-4.2-20060325/gcc/../libdecnumber -I../libdecnumber -o build/read-rtl.o /home/karel/build/gcc-4.2-20060325/gcc/read-rtl.c cc1: warnings being treated as errors /home/karel/build/gcc-4.2-20060325/gcc/read-rtl.c: In function 'join_c_conditions': /home/karel/build/gcc-4.2-20060325/gcc/read-rtl.c:787: warning: missing sentinel in function call gmake[3]: *** [build/read-rtl.o] Error 1 gmake[3]: Leaving directory `/home/karel/build/obj-gcc-4.2-20060325/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/home/karel/build/obj-gcc-4.2-20060325' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/home/karel/build/obj-gcc-4.2-20060325' gmake: *** [bootstrap-lean] Error 2 the compiler used for bootstrap is OpenBSD's gcc3.3.5. GCC 4.2 is configured with: /home/karel/build/gcc-4.2-20060325/configure --prefix=/home/karel/usr/local/gcc-4.2-20060325 --enable-shared --enable-threads --disable-checking --disable-nls --enable-languages=c,c++ and it is build with: gmake CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap-lean If I understand this issue correctly, it seems GCC 4.2 stage1 compiler warns about missing sentinel and because of -Werror bootstrap fails. If this is true, then perhaps the same issue happen also on more supported platforms? (Linux/FreeBSD) If so, then my question is: is this already fixed on trunk? Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: 3.4.3 C++ parsing bug?
On Fri, 11 Feb 2005, Jan Reimers wrote:
> Can someone verify that this is valid C++ before I submit a bug report:
>
> // test.C
> template class A {static T* c;};
>
> class B : public A {};
>
> B* A::c=0;
> // end test.C
>
At least Comeau C++ 4.3.3 and Intel C++ 8.0 compile it and to me it also
looks ok, but I'm not at all C++ language lawer!
Cheers,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
Re: 3.4.3 C++ parsing bug?
On Fri, 11 Feb 2005, Karel Gardas wrote:
> On Fri, 11 Feb 2005, Jan Reimers wrote:
>
> > Can someone verify that this is valid C++ before I submit a bug report:
> >
> > // test.C
> > template class A {static T* c;};
> >
> > class B : public A {};
> >
> > B* A::c=0;
> > // end test.C
> >
>
> At least Comeau C++ 4.3.3 and Intel C++ 8.0 compile it and to me it also
> looks ok, but I'm not at all C++ language lawer!
Thanks to Joe Buck's note, I've found that I've compiled the code with
default, i.e. not so ANSI C++ strict options. I can just confirm that both
Comeau and Intel also fail to compile the code above with proper more
strict options (-A for como, -ansi for icpc).
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
