Re: GCC 4.2.1 Status Report (2007-07-10)

2007-07-12 Thread John David Anglin
 The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th.

PR 32199 is a regression in behavior from 4.2.0.  Although a libjava
build regression is probably not sufficient justification to block
the scheduled release, the change that triggered this regression
has nothing to do the java/libjava.  As of yesterday, libjava still
didn't build on hppa2.0w-hp-hpux11.11 with the 4.2.1 branch.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


Re: GCC 4.2.1 Status Report (2007-07-10)

2007-07-12 Thread Daniel Berlin

On 7/12/07, John David Anglin [EMAIL PROTECTED] wrote:

 The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th.

PR 32199 is a regression in behavior from 4.2.0.  Although a libjava
build regression is probably not sufficient justification to block
the scheduled release, the change that triggered this regression
has nothing to do the java/libjava.


Except it was done to fix insane times compiling other things. It is a
traditional time/space tradeoff for an extremely large file.
I warned at the point I committed it that it may cause issues.
It has indeed caused memory issues on some platforms.
I'm working on some more memory usage reduction for points-to.
Though at some point i can't backport everything in 4.3 into 4.2 to
make it work like 4.3 does.


Re: GCC 4.2.1 Status Report (2007-07-10)

2007-07-11 Thread Richard Guenther

On 7/11/07, Daniel Berlin [EMAIL PROTECTED] wrote:

On 7/11/07, Mark Mitchell [EMAIL PROTECTED] wrote:

 Summary
 ---

 The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th.

 As of 5PM PDT tomorrow, please consider the 4.2 branch closed to all
 changes.  If you have outstanding changes that have been approved, but
 not committed, make the commits before that time.  I plan to build GCC
 4.2.1 RC2 tomorrow evening.

 I will probably wait until a few days after the 13th to build the
 final release, in order to make sure that people have had a chance to
 test out RC2.

 We still have 3 wrong-code P1s:

 PR 32182 -fstrict-aliasing ...

This is not analyzed enough to know whether it's something i should
look at, or the C++ FE people should look at.  IE Nobody has pointed
out what is actually going wrong here, so i don't know whether it's
aliasing or what :)


Also this looks related to PR 32716.

Richard.


Re: GCC 4.2.1 Status Report (2007-07-10)

2007-07-10 Thread Daniel Berlin

On 7/11/07, Mark Mitchell [EMAIL PROTECTED] wrote:


Summary
---

The next scheduled GCC 4.2.x release is GCC 4.2.1 on July 13th.

As of 5PM PDT tomorrow, please consider the 4.2 branch closed to all
changes.  If you have outstanding changes that have been approved, but
not committed, make the commits before that time.  I plan to build GCC
4.2.1 RC2 tomorrow evening.

I will probably wait until a few days after the 13th to build the
final release, in order to make sure that people have had a chance to
test out RC2.

We still have 3 wrong-code P1s:

PR 32182 -fstrict-aliasing ...


This is not analyzed enough to know whether it's something i should
look at, or the C++ FE people should look at.  IE Nobody has pointed
out what is actually going wrong here, so i don't know whether it's
aliasing or what :)


PR 32327 Incorrect stack sharing...



PR 32328 -fstrict-aliasing ...


This i have a patch for, but it really needs some performance testing.
I'm happy to throw it in RC2 if you want to see how it does, with the
caveat it may need to be pulled back out if it causes massive
performance regressions :)


Re: GCC 4.2.1 Status Report (2007-07-10)

2007-07-10 Thread Mark Mitchell
Daniel Berlin wrote:

 PR 32328 -fstrict-aliasing ...
 
 This i have a patch for, but it really needs some performance testing.
 I'm happy to throw it in RC2 if you want to see how it does, with the
 caveat it may need to be pulled back out if it causes massive
 performance regressions :)

No, I don't want to do that -- but thanks for working on the PR.  If you
can do some performance testing up front, then I might consider it for a
post-RC2 inclusion, even if it means an RC3.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713