On Tue, 2005-06-28 at 08:50 -0700, Mark Mitchell wrote:
> Jeffrey A Law wrote:
> > On Tue, 2005-06-28 at 00:20 -0700, Mark Mitchell wrote:
> >
> >>As stated earlier, the only patches I'm considering for 4.0.1 at present
> >>are wrong-code cases on primary platforms. There are several open, but
On Tue, 2005-06-28 at 08:50 -0700, Mark Mitchell wrote:
> Jeffrey A Law wrote:
> > On Tue, 2005-06-28 at 00:20 -0700, Mark Mitchell wrote:
> >
> >>As stated earlier, the only patches I'm considering for 4.0.1 at present
> >>are wrong-code cases on primary platforms. There are several open, but
On Tue, Jun 28, 2005 at 10:06:35AM -0600, Jeffrey A Law wrote:
> On Tue, 2005-06-28 at 08:50 -0700, Mark Mitchell wrote:
> > Perhaps you could get a patch put together, test it by staring
> > atassembly output, and then ask for a volunteer to test it? I expect
> > that Joseph could do a test run
On Tue, 2005-06-28 at 08:50 -0700, Mark Mitchell wrote:
> Perhaps you could get a patch put together, test it by staring
> atassembly output, and then ask for a volunteer to test it? I expect
> that Joseph could do a test run on PA-HPUX for you.
It might be the best bet. I'm going to clean out
Jeffrey A Law wrote:
On Tue, 2005-06-28 at 00:20 -0700, Mark Mitchell wrote:
As stated earlier, the only patches I'm considering for 4.0.1 at present
are wrong-code cases on primary platforms. There are several open, but
the only one I consider a show-stopper is PR 22051, which Jeff Law is
w
On Tue, 2005-06-28 at 00:20 -0700, Mark Mitchell wrote:
> As stated earlier, the only patches I'm considering for 4.0.1 at present
> are wrong-code cases on primary platforms. There are several open, but
> the only one I consider a show-stopper is PR 22051, which Jeff Law is
> working on, and h
Mark Mitchell wrote:
> I'm sorry this is dragging out, but I think it's worth getting this bug
> fixed.
No need for apologies; you're doing the "right thing".
..Scott
As stated earlier, the only patches I'm considering for 4.0.1 at present
are wrong-code cases on primary platforms. There are several open, but
the only one I consider a show-stopper is PR 22051, which Jeff Law is
working on, and hopes to fix Tuesday. As soon as that's in, I'll build
RC3, and
Andrew Pinski wrote:
* PR 21985, in which we are mis-folding expressions involving pointer
arithmetic.
And this is fixed on the mainline already.
The same patch does fix the problem on the branch; I'm now running a
bootstrap/test cycle using that patch.
Thanks,
--
Mark Mitchell
CodeSou
On Jun 23, 2005, at 10:08 AM, Mark Mitchell wrote:
* PR 22043, which involves a failure to initialize fields in automatic
structures. The patch has been applied to the 4.0 branch, but the
target milestone still says 4.0.1. Bugmasters, is that just a
mistake?
Yes this was a mistake.
* PR
As of now, please consider the GCC 4.0 branch completely frozen for all
changes, including documentation, testsuite, etc.
However, I'm not entirely happy with the state of the compiler from the
point of view of doing a release.
There are several PRs for wrong-code in 4.0.1 that seem potential
> And that one should be fixed by the patch I posted, so Solaris
> should be hopefully fine.
Yup, OK everywhere.
--
Eric Botcazou
Volker Reichelt wrote:
Hi Mark,
you wrote
Those who have been watching carefully will note that there is no sign of an
actual
4.0.1 release.
since the branch has been frozen for quite sime time now, a lot of patches
for the 4.0 branch have piled up.
Given the facts that
a) we'll have ano
On Thu, Jun 16, 2005 at 05:10:49PM +0200, Eric Botcazou wrote:
> The diff is attached.
Except that
-_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEil@@GLIBCXX_3.4 FUNC GLOBAL
DEFAULT
the diff just shows the expected 24 changes of @@GLIBCXX_3.4 symbols
to @GLIBCXX_3.4 + @@GLIBCXX_3.4.5 and 2 add
> Can you please post output from
> readelf -Ws libstdc++.so.6 \
>
> | sed -n '/\.symtab/,$d;/ UND /d;/\(GLOBAL\|WEAK\)/p' \
> | awk '{ if ($4 == "OBJECT") { printf "%s %s %s %s %s\n", $8, $4, $5, $6,
> | $3 } else { printf "%s %s %s %s\n", $8, $4, $5, $6 }}' \ LC_ALL=C sort
> | -u
>
> befo
On Thu, Jun 16, 2005 at 10:56:52AM +0200, Eric Botcazou wrote:
> > I would be especially grateful for people testing this on primary hosts
> > that are not linux. In particular, AIX and Solaris.
>
> OK on Solaris 2.5.1 and 2.6, but not OK on Solaris 7, 8, 9 and 10:
Can you please post output from
> I would be especially grateful for people testing this on primary hosts
> that are not linux. In particular, AIX and Solaris.
OK on Solaris 2.5.1 and 2.6, but not OK on Solaris 7, 8, 9 and 10:
FAIL: 27_io/basic_istream/ignore/wchar_t/1.cc (test for excess errors)
WARNING: 27_io/basic_istream/ig
> 1. Benjamin Kosnik reports that there are ABI and/or version-symbol
> problems between 3.4.x and 4.0.x version of libstdc++, and is trying to
> sort out a solution.
I think I have found an acceptable solution for this issue.
Here is more info:
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg013
Hi Mark,
you wrote
> Those who have been watching carefully will note that there is no sign of an
> actual
> 4.0.1 release.
since the branch has been frozen for quite sime time now, a lot of patches
for the 4.0 branch have piled up.
Given the facts that
a) we'll have another relaese candidate
R Hill <[EMAIL PROTECTED]> wrote:
> Dan Kegel wrote:
(Interestingly, the fixes in glibc-cvs
seem to have been made in such a way that
the new glibc won't be compilable by older
versions of gcc, like gcc-3.4.4.
I guess the thinking is that everyone should be using the latest gcc?)
Hmm, do you
Daniel Kegel wrote:
Scott Robert Ladd wrote:
Agreed. I've had mixed reports from folks over in the Gentoo universe
about glibc; perhaps this page might be of interest:
http://process-of-elimination.net/?q=gentoo_and_gcc_4_0_0_tips_and_tricks
Hey Scott.
That page is pretty outdated. AFAIK we
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Andrew Pinski wrote:
> > On Jun 5, 2005, at 1:41 PM, Devang Patel wrote:
> >
> >>
> >> On Jun 5, 2005, at 10:18 AM, Mark Mitchell wrote:
> >>
> >>> Here are three bugs I'd really like to see fixed.
> >>>
> >>> * 21528: SRA and/or aliasing problem.
> >>>
Scott Robert Ladd wrote:
Mark Mitchell wrote:
2. Jakub Jelinek reports that we're miscompiling GLIBC.
[I think this is http://gcc.gnu.org/PR22043 ]
The latter problem seems to me to be as severe as the KDE bug that was
the impetus for this release. ...
Agreed. I've had mixed reports from
Mark Mitchell wrote:
> 2. Jakub Jelinek reports that we're miscompiling GLIBC.
>
> The latter problem seems to me to be as severe as the KDE bug that was
> the impetus for this release. The libstdc++ problem also seems serious.
Agreed. I've had mixed reports from folks over in the Gentoo univers
Those who have been watching carefully will note that there is no sign
of an actual 4.0.1 release.
There are two blocking issues at the moment:
1. Benjamin Kosnik reports that there are ABI and/or version-symbol
problems between 3.4.x and 4.0.x version of libstdc++, and is trying to
sort out
Diego Novillo wrote:
On Sun, Jun 05, 2005 at 10:18:05AM -0700, Mark Mitchell wrote:
* 21528: SRA and/or aliasing problem.
I'll take a look at this tomorrow.
Thanks!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
On Sun, Jun 05, 2005 at 10:18:05AM -0700, Mark Mitchell wrote:
> * 21528: SRA and/or aliasing problem.
>
I'll take a look at this tomorrow.
Diego.
Andrew Pinski wrote:
On Jun 5, 2005, at 2:01 PM, Mark Mitchell wrote:
I agree that these are both serious, though neither seems to rise to
the level of the KDE issues, in that these both affect "only"
debugging. PR 19523 affects only stabs, which I do not think is the
default on any primary
On Jun 5, 2005, at 2:01 PM, Mark Mitchell wrote:
I agree that these are both serious, though neither seems to rise to
the level of the KDE issues, in that these both affect "only"
debugging. PR 19523 affects only stabs, which I do not think is the
default on any primary or secondary platform
Andrew Pinski wrote:
On Jun 5, 2005, at 1:41 PM, Devang Patel wrote:
On Jun 5, 2005, at 10:18 AM, Mark Mitchell wrote:
Here are three bugs I'd really like to see fixed.
* 21528: SRA and/or aliasing problem.
* 21847: DCE over-eagerness.
* 20928: IA32 ICE.
* 19523: [4.0/4.1 Regression]
Steven Bosscher wrote:
On Sunday 05 June 2005 19:29, Mark Mitchell wrote:
Steven Bosscher wrote:
On Sunday 05 June 2005 19:18, Mark Mitchell wrote:
The reason that this release is slightly ahead of schedule is because of
a relatively frequently-encountered wrong-code regression in C++.
Wh
On Jun 5, 2005, at 1:41 PM, Devang Patel wrote:
On Jun 5, 2005, at 10:18 AM, Mark Mitchell wrote:
Here are three bugs I'd really like to see fixed.
* 21528: SRA and/or aliasing problem.
* 21847: DCE over-eagerness.
* 20928: IA32 ICE.
* 19523: [4.0/4.1 Regression] DBX_USE_BINCL support b
On Jun 5, 2005, at 10:18 AM, Mark Mitchell wrote:
Here are three bugs I'd really like to see fixed.
* 21528: SRA and/or aliasing problem.
* 21847: DCE over-eagerness.
* 20928: IA32 ICE.
* 19523: [4.0/4.1 Regression] DBX_USE_BINCL support broken in the C++
compiler
19523 is a nasty regr
On Sunday 05 June 2005 19:29, Mark Mitchell wrote:
> Steven Bosscher wrote:
> > On Sunday 05 June 2005 19:18, Mark Mitchell wrote:
> >>The reason that this release is slightly ahead of schedule is because of
> >>a relatively frequently-encountered wrong-code regression in C++.
> >
> > Which regress
Steven Bosscher wrote:
On Sunday 05 June 2005 19:18, Mark Mitchell wrote:
The reason that this release is slightly ahead of schedule is because of
a relatively frequently-encountered wrong-code regression in C++.
Which regression is this?
The bug that caused KDE miscompilations.
> And w
On Sunday 05 June 2005 19:18, Mark Mitchell wrote:
> The reason that this release is slightly ahead of schedule is because of
> a relatively frequently-encountered wrong-code regression in C++.
Which regression is this? And why does this regression motivate you
to suddenly go release 4.0.1 where
As of midnight, tonight, California time, the GCC 4.0 branch will be
frozen, in preparation for the 4.0.1 release. After that point, all
non-documentation changes will require my explicit approval. To request
approval for a patch, please attach the patch or a pointer thereto to a
PR, and add
There are 163 regressions open against 4.0.1. Of these, 42 are
critical, in the sense that they are wrong-code, ICE-on-valid, or
rejects-valid. That's rather worse than we've done with previous
releases; in part because we're carrying along bugs that we never get
around to fixing from release to
38 matches
Mail list logo
