Mail Archives: pgcc/1998/09/16/19:35:50
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 |
|
- Raw text -