This is the mail archive of the
mailing list for the GCC project.
Just a reminder of serious open 3.3 PRs
- From: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- To: gcc at gcc dot gnu dot org
- Date: 06 Apr 2003 15:38:04 +0200
- Subject: Just a reminder of serious open 3.3 PRs
These are unassigned, poorly analyzed regressions. All PRs I
mention here are still present on the mainline, so even if you don't
care much about 3.3, you still may want to have a look at these PRs ;-)
The two three are serious compile time regressions from 3.2 that should
be show stoppers for 3.3 according to the GCC release criteria. .
opt/8361 [3.3/3.4 regression] C++ compile-time performance regression
This is a 70% slowdown wrt. 3.0.4, and 30% wrt. 3.2.1. It was blamed
on garbage collection and other things, but no real analysis was done
for this problem. The "official" rule from the release criteria
states that "A release candidate's compile-time should not exceed
GCC 2.95.3 by more than 15% ..." Here we have two times the maximum
slowdown with respect to the latest official release.
BTW This is Gerald's PR that tracks g++ slowdown, ref.
http://gcc.gnu.org/ml/gcc/2002-04/msg01168.html (but read "3.3" for "3.2"
in the table, and keep in mind that 3.3 only slowed down *more* since
these timings were done).
opt/10196 [3.3/3.4 regression] Compile time regression with inlining
This is a >1000% slowdown (i.e. more than 10 times the compile time!)
wrt. 3.2.3. The slowdown is in expand, jump, and cfg cleanup, and was
reported for POOMA. Quote from the release criteria says it all:
"POOMA is a complex expression-template library that will tax the ability
of G++ to deal with templates, an area that has historically been buggy.
In addition, templates have historically taken inordinately much time and
memory at compile-time. With the widespread prevalence of templates in C++
programs, including the standard library, testing this area heavily is
Two other PRs I'd like to bring to your attention are these two wrong-code
java/8866 [3.3/3.4 regression] Bug in switch statement code generation -- missing label
Here a complete jump table for a switch statement is being blown away.
Graham Scott said he was working on a fix, but two months have passed
and the bug is still there. The result of problem is clear, but the
cause has not been analysed yet.
opt/8634 [3.2/3.3/3.4 regression] incorrect code for inlining of memcpy under -O2
memcpy a char* buffer, then compare the original to the copy: Not the same?!
Not much analysis, and a rejected workaround patch.
Most other 35 open high-priority PRs are target specific regressions
(probably still present on the mainline as well) or less serious issues
such as ICEs on illegal code or legal but really arcane code (stuff like
inline-asm). 3.3 is IMHO really looking good now, except for these PRs