Re: gEDA-user: Icarus Verilog building from CVS

[Lars Segerlund <lars.segerlund@comsys.se>]

 I agree on most of your points, but I still think you have a problem with either the compile time options for gcc or the flags, and I can understand your position on not pursuing it further.

 Just out of quriosity, what kind of code are you using ? ie. what category as I am using CFD similar memory intensive code. just curious.
 ( there has been a lot of babble about 'sensible' settings for speed out of the box for the compiler, such as using builtins ... ).

 Well, gcc 3.5 is getting more stable day to day, but I would recommend that you pulled it from cvs and did a make bootstrap, any errors occuring should be fixed within a week or two if you send a mail to the gcc list. I haven't got a sparc workstation handy so I can't help you.
 Interesting for you as a c++ user, ( I think you used c++ no ? ), is that there is a new frontend parser for c++ which 'might' be a bit better than the old :-) ...

 I have built gcc for x86, alpha, mips32 and m68k fairly straight out of the box so I am a bit surprised.

 / best regards, Lars Segerlund.


On Mon, 9 Aug 2004 05:51:30 -0400
Dave McGuire <mcguire@neurotica.com> wrote:

> On Aug 9, 2004, at 3:35 AM, Lars Segerlund wrote:
> >  Well, I am running some computationally intensive code, ( CFD ), and 
> > gcc 3.5 ( upcoming ) is giving a boost of up to 30 % for FORTRAN and C 
> > code in some instances.
> >  The 'new' gcc does have a much better optimization framework, and it 
> > is really starting to show, it should fx. be able to run head to head 
> > with intels compiler provided that it is supplied with a reasonable 
> > set of compiler flags, ( which is an area of itself :-) ).
> >  SO if you look for the code generated by the 'state of the art' gcc i 
> > do not believe your statement to be true, ( check out code for the sh 
> > and h8 processors or the mips32 instruction set ).
> 
>    My specifics are UltraSPARC and MIPS.  Binaries generated with GCC 
> (with intelligently-selected optimization flags...I've been a GCC user 
> since v1.38 was current) are, in nearly all cases, significantly slower 
> than with platform-specific vendor compilers.
> 
>    I have no desire to get into a pissing match with you over this.  All 
> I can say is that I'm glad *you* have had good results with GCC.  From 
> my experience, if you're not running x86 (which I'm not) or VAX or M68K 
> (which I rarely do anymore), it sucks.
> 
> >  If you have any cases which can be reduced to misoptimizations please 
> > post a bug report on gcc.gnu.org
> >
> >  If not, ( and from my opinion and experience ), I can only conider 
> > your statement an ill informed opinion.
> 
>    Umm, no, frankly I don't have time to chase optimization issues in 
> GCC.  The current release of GCC doesn't even compile out-of-the-box on 
> the current release of Solaris (my primary development platform).
> 
>    I suppose it's possible that image processing and CFD bring out 
> different strengths and weaknesses in compilers...while I can't imagine 
> this being the case, this is the only thing I can think of that could 
> possibly explain the results you're seeing.
> 
>    And if you *have* managed to get a recent release of GCC to build 
> under Solaris, perhaps you might share a patch.
> 
> >  The big thing I have against the beast is it's compilatioon speed and 
> > memory requirements, it's slow and big.
> 
>    We're in 100% agreement there.
> 
>          -Dave
> 
> --
> Dave McGuire             "...it's a matter of how tightly
> Cape Coral, FL             you pull the zip-tie."       -Nadine Miller
>