X-pop3-spooler: POP3MAIL 2.1.0 b 4 980420 -bs- Message-ID: <19980916205451.59690@cerebro.laendle> Date: Wed, 16 Sep 1998 20:54:51 +0200 From: Marc Lehmann To: Steven Snyder Cc: beastium Subject: Re: Bugs to be fixed in pgcc v1.1.1? Mail-Followup-To: Steven Snyder , beastium References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from Steven Snyder on Wed, Sep 16, 1998 at 09:14:36AM -0500 X-Operating-System: Linux version 2.1.120 (root AT cerebro) (gcc version pgcc-2.91.57 19980901 (egcs-1.1 release)) Status: RO Content-Length: 3722 Lines: 74 On Wed, Sep 16, 1998 at 09:14:36AM -0500, Steven Snyder wrote: > I just read on the egcs mailing list that prioritization of the bugs to be > fixed in egcs v1.1.1 is underway. Presumeably there will also be a > pgcc v1.1.1 release to coincide with the new version of egcs. Yes. > Is there a (tentative, I know) list of problems to be addressed in pgcc > v1.1.1? No. And it would be very small. I'll only fix serious bugs (like a buggy patch, or some serious omission), but not subtle bugs. Backporting fixes is very time consuming, just look at the recent changes in egcs ;) Everybody wants to add new features now ;) > On a related topic, I'd be interested in knowing which reported problems > have been confirmed as genuine bugs in pgcc. That way I'd know which Usually, bug reports that I get and classify get fixed very quickly, the remaining reports is still unclassified so I don't have a large dataset (but see below). - pgcc has problems with aliasing in many cases. gcc makes some (undocumented) guarentees about aliasding that gcc doesn't (like accessing ints as shorts). Unfortunately, it sometimes does so even when you use unions, which is explicitly allowed in C. The occurence of this bug is rare. - pgcc-1.1 has problems with -ffast-math, where its omitting some instructions. The snapshots are safe from this, but the change is large. - pgcc creates very very suboptimal code for p-ii's. while this has improved in the last week, -mk6 is still often faster than -mpentiumpro on ppro (but this is similar for egcs, where k6 optimized code often runs faster as well :() These are the only known bugs in pgcc. There are, though, other bugs that _only occur_ in pgcc, although their root lies in egcs. Egcs is developing very quickly. Often new optimizations generate slightly wrong code that still assembles correctly, but some additional pass in pgcc gets confused and breaks the code totally. These kind of errors are very frequent, but go away after some time (a month or so), when egcs is fixed, and usually are not important in the well-tested egcs-releases (this is a reason why I often "ignore" a bug-report for some time when it looks like a temporary bug). And a large part of bug-reports I receive is either somebody having a g++ program that isn't correct c++, a missing volatile or an aliasing problem, i.e. source bugs. Fortunately these are often easy to spot. > compiling contexts to pay particular attention to. Well, -march=pentiumpro is a relatively recent addition to egcs (it was disabled for a very long time), and a very complex one, thus be careful with this. The union-aliasing problem can be worked around with -fpeep-spills, and compiling pgcc with -O3 or higher (or -march=pentiumpro) is generally a very bad idea. Also, many asm()'s were written with gcc-2.7.2 in mind, but don't work in pgcc and will generate either incorrect code or the compiler will stop. egcs has similar problems. Also, asm's are overused in many programs (it wasn't designed for genberal assembly programming), and pgcc, due to its more aggressive register usage, will get caught in a cul-de-sac where no register is free to spill more often than egcs. This is a "bug" because gcc behaves not like documented. Does this answer your questions? -----==- | ----==-- _ | ---==---(_)__ __ ____ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / pcg AT goof DOT com |e| -=====/_/_//_/\_,_/ /_/\_\ --+ The choice of a GNU generation | |