GCC 3.3 release

GCC 3.3 release

[Mark Mitchell]

There are presently 53 outstanding high-priority 3.3 regressions.

Some of these look pretty minor, and we could probably do a release
even with those problems; in particular, there are several reports of
missing or spurious warnings and/or documentation issues.

Nearly half of the bugs are optimization problems, however.  These are
especially serious in that many seem to involve bad behavior on legal
code.  Most of these are still present in 3.4 as well, so we need to
fix these.

Overall, I think the 3.3 release is starting to gel nicely.  If our
skilled middle-end/back-end people will each knock down a few of these
regressions, we'll be there quickly.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.3 release

[Steven Bosscher]

Op vr 21-03-2003, om 20:25 schreef Mark Mitchell:
> Overall, I think the 3.3 release is starting to gel nicely.

There are still some critical PRs, and a few that are "serious" but
should be "critical" (the inline and compile time issues).  Do you think
those are show stoppers?

Do you have a release plan for 3.3.x, and a rough development plan for
3.4?

Greetz
Steven

Re: GCC 3.3 release

[Mark Mitchell]

On Fri, 2003-03-21 at 17:32, Steven Bosscher wrote:
> Op vr 21-03-2003, om 20:25 schreef Mark Mitchell:
> > Overall, I think the 3.3 release is starting to gel nicely.
> 
> There are still some critical PRs, and a few that are "serious" but
> should be "critical" (the inline and compile time issues).  Do you think
> those are show stoppers?

Yes -- if there were no show stoppers, I'd spin the release right now.

We're getting closer, but we definitely need to knock down a bunch of
the remaining ones.

> Do you have a release plan for 3.3.x, and a rough development plan for
> 3.4?

I don't want to worry too much about 3.4 until we get 3.3 out the door;
for example, if 3.3 were to take a lot longer to get done, it would make
sense to let more into 3.4 than it would if 3.3 is done tomorrow (which
it won't be.)

For 3.3, I think all we need to do is to fix the high-priority PRs. 
It's hard for me to say how long that will take, but I would think that
if we all pull together not very long.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

PATCH for Re: GCC 3.3 release

[Gerald Pfeifer]

On Sat, 22 Mar 2003, Steven Bosscher wrote:
> Do you have a release plan for 3.3.x, and a rough development plan for
> 3.4?

Which reminds me, that the best we probably can do at this point (not
the least because we are a volunteer project) is the following patch.

Installed.

Gerald

Remove dates for GCC 3.3 and 3.3.1; add GCC 3.2.3 (without a date).

Index: develop.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.29
diff -u -3 -p -r1.29 develop.html
--- develop.html	5 Feb 2003 05:14:05 -0000	1.29
+++ develop.html	26 Mar 2003 19:16:51 -0000
@@ -263,6 +263,9 @@ stages of development, branch points, an
        |                                              \
        |                                               v
        |                                   GCC 3.2.2 release (Feb 05 2003)
+       |                                                \
+       |                                                 v
+       |                                   GCC 3.2.3 release (...)
        v
   GCC 3.3 Stage 2 (ends Aug 15 2002)
        |
@@ -273,10 +276,10 @@ stages of development, branch points, an
        +-- GCC 3.3 branch created ------+
        |              (Dec 14 2002)      \
        :                                  v
-       :                                   GCC 3.3 release (Mar 1 2003)
+       :                                   GCC 3.3 release (...)
        :                                    \
                                              v
-                                           GCC 3.3.1 release (May 1 2003)
+                                           GCC 3.3.1 release (...)

 </pre>

Re: PATCH for Re: GCC 3.3 release

[Gabriel Dos Reis]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

[...]

| Remove dates for GCC 3.3 and 3.3.1; add GCC 3.2.3 (without a date).

GCC-3.2.3 is scheduled for 15th April.  I'll commit a patch in a
moment. 

Thank you for the remind.

-- Gaby

Re: GCC 3.3 release

[Gunther Nikl]

On Mon, Mar 24, 2003 at 12:07:57PM +0100, Andreas Schwab wrote:
> Gunther Nikl <gni@gecko.de> writes:
> 
> |> On Fri, Mar 21, 2003 at 20:56:41 -0500, Nathanael Nerode wrote:
> |> > It would also be nice if 3.3 could bootstrap itself successfully on 
> |> > m68k; there seem to be a number of frightening bugs preventing 3.2 from 
> |> > doing so, but the m68k experts will have to look at them.
> |> 
> |>   AFAICT, the bug(s) preventing a bootstrap on m68k is (are) with
> |>   "long long". After I disabled "long long" in auto-host.h I could
> |>   build a working 3.2.2 on m68k with GCC 2.95.2 and 2.7.2.1. I suspect
> |>   thats is a long standing problem still present since a m68k GCC 3.2.2
> |>   with "long long" enabled in auto-host.h shows the same symtoms as a
> |>   natively built GCC 3.2.2 (compiled with either 2.95.2 or 2.7.2.1).
> 
> Have you already tried with current CVS where the iordi3 bug is fixed?

I checked 3.2.2 with the iordi3 patch included and a native GCC 3.2.2 is
still broken :-/ I verified that the patch is included in the used 3.2.2
cc1 by compiling the sample testcase from the pr. (BTW, 2.7.2.1 doesn't
have that problem since the generated code for the pr testcase is correct.
egcs 1.0.3 and 1.1 do have that bug).
However, I also tried a native 3.3/20030303 and that version _does_ work.
At least it could compile 3.2.2 with "long long" enabled and the resulting
xgcc didn't barf when compiling libgcc.a as it did when compiled by eg.
2.95.2 and "long long" enabled. I didn't try a bootstrap since that would
need to much time which I currently don't have.
Building a native m68k 3.3/20030303 with a m68k cross-gcc showed a problem
during compilation of ra-colorize.c with -O1. With -O1 the compiler emits
unused and incomplete switch jump-tables eg. in ra-colorize.c/reset_lists.
I guess this happens when inlining put_web(). Specifying -fgcse fixes that.

Gunther

Re: GCC 3.3 release

[Gunther Nikl]

On Mon, Mar 24, 2003 at 12:07:57PM +0100, Andreas Schwab wrote:
> Gunther Nikl <gni@gecko.de> writes:
> 
> |> On Fri, Mar 21, 2003 at 20:56:41 -0500, Nathanael Nerode wrote:
> |> > It would also be nice if 3.3 could bootstrap itself successfully on 
> |> > m68k; there seem to be a number of frightening bugs preventing 3.2 from 
> |> > doing so, but the m68k experts will have to look at them.
> |> 
> |>   AFAICT, the bug(s) preventing a bootstrap on m68k is (are) with
> |>   "long long". After I disabled "long long" in auto-host.h I could
> |>   build a working 3.2.2 on m68k with GCC 2.95.2 and 2.7.2.1. I suspect
> |>   thats is a long standing problem still present since a m68k GCC 3.2.2
> |>   with "long long" enabled in auto-host.h shows the same symtoms as a
> |>   natively built GCC 3.2.2 (compiled with either 2.95.2 or 2.7.2.1).
> 
> Have you already tried with current CVS where the iordi3 bug is fixed?

  Not yet. I already fetched that patch, applied it to my 3.3 snapshot and
  compiled cc1. Then I checked the result of the testcase from the pr.
  cc1 without patch trashed "d2", cc1 with that patch didn't. I am going
  to check 3.2.2 and a 3.3 snapshot with that patch on my m68k system.
  It will take some time since I need one hour to build an unoptimized 3.x
  compiler with GCC 2.x. I guess using a 3.x version will increase compile
  time.

  Gunther

Re: GCC 3.3 release

[Andreas Schwab]

Gunther Nikl <gni@gecko.de> writes:

|> On Fri, Mar 21, 2003 at 20:56:41 -0500, Nathanael Nerode wrote:
|> > It would also be nice if 3.3 could bootstrap itself successfully on 
|> > m68k; there seem to be a number of frightening bugs preventing 3.2 from 
|> > doing so, but the m68k experts will have to look at them.
|> 
|>   AFAICT, the bug(s) preventing a bootstrap on m68k is (are) with
|>   "long long". After I disabled "long long" in auto-host.h I could
|>   build a working 3.2.2 on m68k with GCC 2.95.2 and 2.7.2.1. I suspect
|>   thats is a long standing problem still present since a m68k GCC 3.2.2
|>   with "long long" enabled in auto-host.h shows the same symtoms as a
|>   natively built GCC 3.2.2 (compiled with either 2.95.2 or 2.7.2.1).

Have you already tried with current CVS where the iordi3 bug is fixed?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GCC 3.3 release

[Gunther Nikl]

On Fri, Mar 21, 2003 at 20:56:41 -0500, Nathanael Nerode wrote:
> It would also be nice if 3.3 could bootstrap itself successfully on 
> m68k; there seem to be a number of frightening bugs preventing 3.2 from 
> doing so, but the m68k experts will have to look at them.

  AFAICT, the bug(s) preventing a bootstrap on m68k is (are) with
  "long long". After I disabled "long long" in auto-host.h I could
  build a working 3.2.2 on m68k with GCC 2.95.2 and 2.7.2.1. I suspect
  thats is a long standing problem still present since a m68k GCC 3.2.2
  with "long long" enabled in auto-host.h shows the same symtoms as a
  natively built GCC 3.2.2 (compiled with either 2.95.2 or 2.7.2.1).

  Gunther

Re: GCC 3.3 release

[Steven Bosscher]

Op za 22-03-2003, om 02:56 schreef Nathanael Nerode:
> 10087 (multidimensional array problem)

Janis hunted this one, see
http://gcc.gnu.org/ml/gcc-bugs/2003-03/msg00942.html.
There was a patch submitted yesterday to fix it.

Greetz
Steven

Re: GCC 3.3 release

[Nathanael Nerode]

Op vr 21-03-2003, om 20:25 schreef Mark Mitchell:
> Overall, I think the 3.3 release is starting to gel nicely.

Steven Bosscher said:
>There are still some critical PRs, and a few that are "serious" but
>should be "critical" (the inline and compile time issues).  Do you 
>think those are show stoppers?

I nominate the following as show stoppers for 3.3.  They're all silent
wrong code emission bugs, and regressions.

8634 (incorrect inlining of memcpy under -O2)

9745 (loop alias problem)

10021 (another loop alias problem, causes some of the m68k bustage)

10087 (multidimensional array problem)

10171 (the infamous 'lost loop' bug)

10185 (more loop bugs)

8866 (jumptable->jump problem)

Some of these are probably down to the same fundamental bug.

It would also be nice if 3.3 could bootstrap itself successfully on 
m68k; there seem to be a number of frightening bugs preventing 3.2 from 
doing so, but the m68k experts will have to look at them.

That would be more than sufficient for my tastes. :-)