Re: List of bugs that *must* be fixed before releasing Hamm
On Fri, May 29, 1998 at 10:40:09AM -0400, Brian White wrote:
> > > Would it be possible to remove "-force-mem" from the list of
> > > optimizations done by "-O2"?
> >
> > I don't know. I'm not an expert on (e)gcc internals.
>
> My problem is that a lot of people use "-O2" for their compiles. If egcs
> breaks when doing that then it would be a fairly common occurance.
What the bug report shows is that there are occasions where -O2 fails; it
does not indicate that this is a fairly common occurance. Given the nature
of this bug report, I doubt it will affect many packages.
> The question I ask is whether these problems (and the numerous bug reports
> that will flow from it) are worth the benefits derived from keeping egcs
> in Hamm. My general thinking on this is "no".
>
> Please tell me your opinions on this.
In my opinion, there are three compiler suites we could consider for hamm:
- gcc 2.7.2.3 . This is very solid for C, but it does not support many
constructs and features used in C++ nowadays. I'm not familiar enough with
Objective C to comment on its performance in that area.
Also, it only supports some of our architectures properly.
- gcc 2.8.x . This has improved C++ support compared to 2.7.2.x, but is
(as far as I can gather from following Usenet) not as good as egcs for
C++, and appears to have undergone less testing then egcs.
The FSF's gcc development is still very cathedral, so the chances of
getting bugs we find in it fixed within an acceptable time are small.
- egcs 1.0.x (which roughly is a further development on top of 2.8.x).
This currently provides the primary C compiler on some of
our architectures (and appears to be very stable). It supports a
large part of the C++ standard, and appears to work fine for that
language. It's Objective C compiler is also used successfully for
packages like GNUstep.
It is developed in bazaar-style fashion, with a fast release schedule,
and very fast snapshot releases. This increases user participation and
contributes to getting bugs fixed in a timely fashion.
Another reason why I feel positive about egcs is that it comes with an
integrated testsuite, making it clear that there is a lot of attention
for the quality of its release versions.
Galen introduced the current two-suites situation in hamm for reasons that I
find sound. Matthias and I have maintained and documented this situation in
our non-maintainer work.
> The point about egcs being the primary c++ compiler is a good one. I
> hadn't realized that. This makes egcs a much higher priority package (in
> my mind, at least) and Debian should ship with a functioning c++ compiler.
>
> That leaves three choices that I see:
> - delay Hamm until -force-mem gets fixed
> - delay Hamm until -O2 no longer sets -force-mem
> - ship Hamm with a bug likely to show up often
>
> Does this seem accurate to you?
I disagree with the phrasing of the third option, but I admit that I don't
have hard factual data to back up my assesment that it is not likely to show
up often.
> I would think (note: I have no experience with gcc code) that doing the
> second would not be a tremendous effort, but I'm not sure.
I've just done a quick grep through the source code, and it is controlled by
a separate flag variable (flag_force_mem), so the chances of this being
doable look good.
Greetings,
Ray
--
ART A friend of mine in Tulsa, Okla., when I was about eleven years old.
I'd be interested to hear from him. There are so many pseudos around taking
his name in vain.
- The Hipcrime Vocab by Chad C. Mulligan
--
To UNSUBSCRIBE, email to debian-qa-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: