And http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39886
This one is relatively rare, so no. Feel free to pick up the patch, I
already have too many approved patches that I cannot get round to test
and commit.
Paolo
> On what date?
See http://gcc.gnu.org/ml/gcc-testresults/2009-09
--
Eric Botcazou
> I will rebuild with the head and run ACATS on
> one of the broken ones. If still bad, then
> I will try with some simple exception tests
> Laurent put together the last time it broke.
> Maybe they are useful again. :)
Were they added to the gnat.dg testsuite? If no, they should.
--
Eric Botc
Eric Botcazou wrote:
Joel reported results for 4.5.0 20090910 r151592 and state of GCC
changed a lot in the past 9 days. RTEMS is also a sjlj target IIRC.
Then, if EH is totally broken, a PR should be opened with a reduced testcase.
I will rebuild with the head and run ACATS on
one of
Laurent GUERBY wrote:
On Sat, 2009-09-19 at 16:58 +0200, Eric Botcazou wrote:
I need to get run baseline test results on 4.3 and 4.4 for C and
C++. But the GNAT/RTEMS Ada results show a large number of
failures on the head that were not present in 4.3 and 4.4.
SPARC and MIPS went from 2 to
> Joel reported results for 4.5.0 20090910 r151592 and state of GCC
> changed a lot in the past 9 days. RTEMS is also a sjlj target IIRC.
Then, if EH is totally broken, a PR should be opened with a reduced testcase.
--
Eric Botcazou
On Sat, 2009-09-19 at 16:58 +0200, Eric Botcazou wrote:
> > I need to get run baseline test results on 4.3 and 4.4 for C and
> > C++. But the GNAT/RTEMS Ada results show a large number of
> > failures on the head that were not present in 4.3 and 4.4.
> >
> > SPARC and MIPS went from 2 to 319
> > x
2009/9/19 H.J. Lu :
> On Sat, Sep 19, 2009 at 7:58 AM, Eric Botcazou wrote:
>>> I need to get run baseline test results on 4.3 and 4.4 for C and
>>> C++. But the GNAT/RTEMS Ada results show a large number of
>>> failures on the head that were not present in 4.3 and 4.4.
>>>
>>> SPARC and MIPS wen
On Sat, Sep 19, 2009 at 7:58 AM, Eric Botcazou wrote:
>> I need to get run baseline test results on 4.3 and 4.4 for C and
>> C++. But the GNAT/RTEMS Ada results show a large number of
>> failures on the head that were not present in 4.3 and 4.4.
>>
>> SPARC and MIPS went from 2 to 319
>> x86 went
> I need to get run baseline test results on 4.3 and 4.4 for C and
> C++. But the GNAT/RTEMS Ada results show a large number of
> failures on the head that were not present in 4.3 and 4.4.
>
> SPARC and MIPS went from 2 to 319
> x86 went from about 20 (mostly qemu issues) to 225
OK, but the numbe
DaveK
What is slush?
A phase of development when we stop adding new code and merging new features
for a while and go into bug-fix only mode to let trunk stabilise when there
are significant numbers of high-impact open PRs impeding the smooth progress
of development.
From the
Dave Korn wrote:
A phase of development when we stop adding new code and merging new features
for a while and go into bug-fix only mode to let trunk stabilise when there
are significant numbers of high-impact open PRs impeding the smooth progress
of development.
+1
Cheers,
Angelo.
> Should we perhaps, again? I'm having trouble fixing one bootstrap-breaking
> bug because of a second one that's piled in on top of it right now; how is it
> for other targets?
Bad for darwin!-(bootstrap failing since at least r151822, see pr41405).
If you add pr41407+oth
ts?
>>
>>cheers,
>> DaveK
>>
>>
>
> What is slush?
A phase of development when we stop adding new code and merging new features
for a while and go into bug-fix only mode to let trunk stabilise when there
are significant numbers of high-impact open PRs impeding
On Sat, Sep 19, 2009 at 5:51 AM, Dave Korn
wrote:
>
> Should we perhaps, again? I'm having trouble fixing one bootstrap-breaking
> bug because of a second one that's piled in on top of it right now; how is it
> for other targets?
>
> cheers,
> DaveK
>
>
What is slush?
Should we perhaps, again? I'm having trouble fixing one bootstrap-breaking
bug because of a second one that's piled in on top of it right now; how is it
for other targets?
cheers,
DaveK
problems. I
still see a bootstrapping PR (PR39929), but it's unclear to me whether
there are still problems there or not. Given the progress, the slush is
over.
However, Paolo Bonzini has announced the intention to merge the
cond-optab branch on Friday. Therefore, until that is done, plea
On Tue, Apr 28, 2009 at 11:12 PM, Mark Mitchell wrote:
> We're in Stage 1, and in Stage 1 big changes happen -- and then there is
> naturally some instability. We clearly have some instability at
> present, so we need to slow down until that's resolved.
Bah.
> With the benefit of hindsight, I
We're in Stage 1, and in Stage 1 big changes happen -- and then there is
naturally some instability. We clearly have some instability at
present, so we need to slow down until that's resolved.
Therefore, effective immediately, please commit only bug fixes to the
middle end and to architectures th
Hans-Peter Nilsson wrote:
> I don't see a request, yet more than two people seem to agree,
> so: can we have a slush (no new merges or features) while the
> tree is stabilized?
>
> I'll let other people answer the "why" wrt. priority platforms;
> the
On Tue, Apr 28, 2009 at 7:17 AM, Hans-Peter Nilsson wrote:
> I don't see a request, yet more than two people seem to agree,
> so: can we have a slush (no new merges or features) while the
> tree is stabilized?
>
> I'll let other people answer the "why" wr
I don't see a request, yet more than two people seem to agree,
so: can we have a slush (no new merges or features) while the
tree is stabilized?
I'll let other people answer the "why" wrt. priority platforms;
the double breakages for cris-elf (PR39927, PR39938) don't
count. :/
brgds, H-P
Bob Wilson wrote:
> Mark Mitchell wrote:
>> When I sent out the notice about GCC 4.2.2 RC1, I failed to note the GCC
>> 4.2 branch should now be considered slushy; please get my explicit
>> approval before check-in. Obviously, there was no way anyone could have
>> known that, so if things have bee
Mark Mitchell wrote:
When I sent out the notice about GCC 4.2.2 RC1, I failed to note the GCC
4.2 branch should now be considered slushy; please get my explicit
approval before check-in. Obviously, there was no way anyone could have
known that, so if things have been checked in since the announc
When I sent out the notice about GCC 4.2.2 RC1, I failed to note the GCC
4.2 branch should now be considered slushy; please get my explicit
approval before check-in. Obviously, there was no way anyone could have
known that, so if things have been checked in since the announcement
that's fine; I'll
Richard Earnshaw wrote:
It's probably too late to do anything about this one this time around,
but isn't this why we have branches? The whole point of having branch
developments is so that potentially destabilizing chanes (such as
adding/changing major interfaces) can be done without causing th
On Mon, 2005-05-23 at 11:43 -0700, Mark Mitchell wrote:
> Fair enough. Would you mind reporting back later today, then? One
> possibility is to do the changes that fix our primary languages (C, C++,
> and Java, since it's easy) and deal with Fortran later. If we can get
> the mainline bootst
On Mon, 2005-05-23 at 17:36, Jeffrey A Law wrote:
> On Mon, 2005-05-23 at 17:25 +0100, Richard Earnshaw wrote:
> > However, in the mean-time I'm stuck. I can't build my world anymore, so
> > I can't test the compiler
> I understand. But realize that I'm trying to ultimately save you time
> i
ips-sgi-irix6.5: OK
i686-pc-linux-gnu: OK
I know that's not perfect, but I think we can move forward. We
certainly seem to be bootstrapping on most platforms. At the same time,
I don't want to destabilize things if Jeff et. al. are trying to get
cleanups done.
So, let's
On Mon, 2005-05-23 at 19:35 +0200, Steven Bosscher wrote:
> On Monday 23 May 2005 18:20, Jeffrey A Law wrote:
> > I'd much rather take the time to fix all these problems, install the
> > fixes along with the checking bits to ensure they never come back
> > rather than to iterate on each one separat
Jeffrey A Law wrote:
On Mon, 2005-05-23 at 11:04 -0700, Mark Mitchell wrote:
Jeffrey A Law wrote:
much rather bite the bullet and get them fixed now. The fact that it's
affecting a lot of people keep the coals hot on my feet :-)
Jeff --
I know you're doing everything you can to fix the pr
On Mon, 2005-05-23 at 11:04 -0700, Mark Mitchell wrote:
> Jeffrey A Law wrote:
> > much rather bite the bullet and get them fixed now. The fact that it's
> > affecting a lot of people keep the coals hot on my feet :-)
>
> Jeff --
>
> I know you're doing everything you can to fix the problems. D
Jeffrey A Law wrote:
much rather bite the bullet and get them fixed now. The fact that it's
affecting a lot of people keep the coals hot on my feet :-)
Jeff --
I know you're doing everything you can to fix the problems. Do you have
an ETA for a solution? Probably if it's on the order of a
On Monday 23 May 2005 18:20, Jeffrey A Law wrote:
> I'd much rather take the time to fix all these problems, install the
> fixes along with the checking bits to ensure they never come back
> rather than to iterate on each one separately.
And int the mean time, things stay broken?
Gr.
Steven
On Mon, 2005-05-23 at 17:25 +0100, Richard Earnshaw wrote:
> On Mon, 2005-05-23 at 17:20, Jeffrey A Law wrote:
> > On Mon, 2005-05-23 at 16:34 +0100, Richard Earnshaw wrote:
> > > On Mon, 2005-05-23 at 16:19, Eric Christopher wrote:
> > > > > > http://gcc.gnu.org/wiki/GCC%204.1%20Slush
> > > > >
On Mon, 2005-05-23 at 12:19 -0400, Daniel Berlin wrote:
> >
>
> Originally, this is one of the reasons the patch was not committed:
> There were places in fortran that weren't clean, etc, and i just didn't
> have time to go hunting (which is why i posted it to gcc patches, and
> left it out there
On Mon, 2005-05-23 at 17:20, Jeffrey A Law wrote:
> On Mon, 2005-05-23 at 16:34 +0100, Richard Earnshaw wrote:
> > On Mon, 2005-05-23 at 16:19, Eric Christopher wrote:
> > > > > http://gcc.gnu.org/wiki/GCC%204.1%20Slush
> > > >
> > > > Just to let folks know that mips-elf fails to build newlib.
On Mon, 2005-05-23 at 16:34 +0100, Richard Earnshaw wrote:
> On Mon, 2005-05-23 at 16:19, Eric Christopher wrote:
> > > > http://gcc.gnu.org/wiki/GCC%204.1%20Slush
> > >
> > > Just to let folks know that mips-elf fails to build newlib.
> > > There's a segfault in is_gimple_reg_type(), which is b
On Mon, 2005-05-23 at 10:00 -0600, Jeffrey A Law wrote:
> On Mon, 2005-05-23 at 11:42 -0400, Eric Christopher wrote:
> > > Eric (and anyone else who wasn't aware): there's been a lot of
> > > discussion about this on gcc-patches since I posted that message:
> > >
> > > http://gcc.gnu.org/ml/gc
On Mon, 2005-05-23 at 11:42 -0400, Eric Christopher wrote:
> > Eric (and anyone else who wasn't aware): there's been a lot of
> > discussion about this on gcc-patches since I posted that message:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02029.html
> >
> > It's also PR21638:
> >
>
> Eric (and anyone else who wasn't aware): there's been a lot of
> discussion about this on gcc-patches since I posted that message:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02029.html
>
> It's also PR21638:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21638
>
> It looks lik
Eric Christopher <[EMAIL PROTECTED]> writes:
>> > http://gcc.gnu.org/wiki/GCC%204.1%20Slush
>>
>> Just to let folks know that mips-elf fails to build newlib.
>> There's a segfault in is_gimple_reg_type(), which is being
>> passed a null type. I'm not sure if I'll have time to look
>> at it toni
On Mon, 2005-05-23 at 16:19, Eric Christopher wrote:
> > > http://gcc.gnu.org/wiki/GCC%204.1%20Slush
> >
> > Just to let folks know that mips-elf fails to build newlib.
> > There's a segfault in is_gimple_reg_type(), which is being
> > passed a null type. I'm not sure if I'll have time to look
> > http://gcc.gnu.org/wiki/GCC%204.1%20Slush
>
> Just to let folks know that mips-elf fails to build newlib.
> There's a segfault in is_gimple_reg_type(), which is being
> passed a null type. I'm not sure if I'll have time to look
> at it tonight.
I took a look and it seemed to work for me,
Andreas Jaeger <[EMAIL PROTECTED]> wrote on 22/05/2005 17:29:24:
> On Sun, May 22, 2005 at 05:25:13PM +0300, Dorit Naishlos wrote:
> > I also see these failures on powerpc-apple-darwin, but they are all
solved
> > when I apply Keith's patch:
> > http://gcc.gnu.org/ml/gcc-patches/2005-05/msg0080
On Sun, May 22, 2005 at 05:25:13PM +0300, Dorit Naishlos wrote:
> I also see these failures on powerpc-apple-darwin, but they are all solved
> when I apply Keith's patch:
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00803.html
His patch was approved under the condition that a few
things get modi
> Eric Botcazou <[EMAIL PROTECTED]> writes:
>
> >> On Sat, May 21, 2005 at 12:16:27AM +0200, Eric Botcazou wrote:
> >> > http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01339.html
> >>
> >> The vectorization failures still need to be fixed.
> >
> > Are these specific to SPARC? If so, I don't
> On Sunday 22 May 2005 00:16, Jan Hubicka wrote:
> > (not sure of -fdump-rtl-expand ever worked, but I
> > might try to restore it if it did).
>
> It very definitely did work, and quite nicely too.
> Try -fdump-rtl-expand-details.
Yeah, but on tree-profiling it always was -fdump-tree-expand-detai
On Sun, 2005-05-22 at 00:16 +0200, Jan Hubicka wrote:
> > On Sat, May 21, 2005 at 09:45:38PM +0200, Eric Botcazou wrote:
> > > Btw, is it me or the individual RTL dump options are broken?
> >
> > The initial rtl dump is broken. The rest work.
> >
> > I think one of Jan's IPA pass manager changes
On Sunday 22 May 2005 00:16, Jan Hubicka wrote:
> (not sure of -fdump-rtl-expand ever worked, but I
> might try to restore it if it did).
It very definitely did work, and quite nicely too.
Try -fdump-rtl-expand-details.
Gr.
Steven
> On Sat, May 21, 2005 at 09:45:38PM +0200, Eric Botcazou wrote:
> > Btw, is it me or the individual RTL dump options are broken?
>
> The initial rtl dump is broken. The rest work.
>
> I think one of Jan's IPA pass manager changes broke it.
What are the symptoms? -fdump-tree-expand seems to wo
On Sat, May 21, 2005 at 09:45:38PM +0200, Eric Botcazou wrote:
> Btw, is it me or the individual RTL dump options are broken?
The initial rtl dump is broken. The rest work.
I think one of Jan's IPA pass manager changes broke it.
r~
> The new implementation of instantiate_virtual_regs requires that the
> insn be valid *before* instantiation.
I see. I didn't find it written anywhere so I thought I should ask.
> The bug is in sparc_emit_float_lib_cmp,
>
> 5807 slot0 = assign_stack_temp (TFmode, GET_MODE_SIZE(TFmo
On Sat, May 21, 2005 at 10:46:19AM +0200, Eric Botcazou wrote:
> We have as initial RTL:
>
> (insn 35 34 36 1 (set (mem/i:TF (plus:DI (reg/f:DI 103 virtual-stack-vars)
> (const_int -5120 [0xec00])) [0 S16 A128])
> (reg:TF 110 [ D.1221 ])) -1 (nil)
> (nil))
>
On Sat, May 21, 2005 at 10:59:44AM +0200, Jan Hubicka wrote:
> I believe Andrew mentioned that there is a patch for this? (it is lack
> of sync in between operands and stmt itself)
The last state I saw is that the patch needed some minor updates.
I was hoping that one of the original authors woul
> On Sat, May 21, 2005 at 09:08:45AM +0200, Eric Botcazou wrote:
> > Are these specific to SPARC?
>
> No.
I believe Andrew mentioned that there is a patch for this? (it is lack
of sync in between operands and stmt itself)
Honza
>
>
> r~
> The struct-layout-1 failures in 64-bit mode are IMHO more annoying, but
> these tests are easy to break so I'm not really worried either.
Huh, I was wrong, they are quite problematic. Testcase attached.
We have as initial RTL:
(insn 35 34 36 1 (set (mem/i:TF (plus:DI (reg/f:DI 103 virtual-sta
Eric Botcazou <[EMAIL PROTECTED]> writes:
>> On Sat, May 21, 2005 at 12:16:27AM +0200, Eric Botcazou wrote:
>> > http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01339.html
>>
>> The vectorization failures still need to be fixed.
>
> Are these specific to SPARC? If so, I don't think development s
On Sat, May 21, 2005 at 09:08:45AM +0200, Eric Botcazou wrote:
> Are these specific to SPARC?
No.
r~
> On Sat, May 21, 2005 at 12:16:27AM +0200, Eric Botcazou wrote:
> > http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01339.html
>
> The vectorization failures still need to be fixed.
Are these specific to SPARC? If so, I don't think development should be held
off for them at this point. If not
On Sat, May 21, 2005 at 12:16:27AM +0200, Eric Botcazou wrote:
> http://gcc.gnu.org/ml/gcc-testresults/2005-05/msg01339.html
The vectorization failures still need to be fixed.
r~
Yes, he checked in my change, and didn't copy me on the email... Also,
something ate my gcc-patches email. :-(
No, I checked it in before seeing your other message with the proposed
fix. My apologies for not giving credit.
(Indeed the fix is a bit different, I replaced \0 with the portable &
Yes, he checked in my change, and didn't copy me on the email... Also,
something ate my gcc-patches email. :-(
No, I checked it in before seeing your other message with the proposed
fix. My apologies for not giving credit.
(Indeed the fix is a bit different, I replaced \0 with the portable &
On May 19, 2005, at 2:53 PM, Bryce McKinlay wrote:
Was this not fixed by:
2005-05-18 Paolo Bonzini <[EMAIL PROTECTED]>
* Makefile.am (Makefile.deps): Do not use \0, it is unportable.
* Makefile.in: Regenerate.
?
Yes, he checked in my change, and didn't copy me on the email...
Also, somet
Was this not fixed by:
2005-05-18 Paolo Bonzini <[EMAIL PROTECTED]>
* Makefile.am (Makefile.deps): Do not use \0, it is unportable.
* Makefile.in: Regenerate.
?
Bryce
David Daney wrote:
Perhaps sending this to java-patches will help...
Mike Stump wrote:
On May 19, 2005, at 10:11 AM, Mark Mi
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Richard Henderson wrote:
>> After three days of sequential bootstrap breakage, I'd like to propose
>> that mainline go into slush, wherein all these bootstrap problems, and
>> all the new testsuites failures get f
Perhaps sending this to java-patches will help...
Mike Stump wrote:
On May 19, 2005, at 10:11 AM, Mark Mitchell wrote:
Nobody's objected, and it's fine by me. So, let's do it.
Ping.
I kinda wish someone would review the libjava breakage patch for darwin...
http://gcc.gnu.org/ml/gcc-patches/2005-
On May 19, 2005, at 2:13 PM, Mike Stump wrote:
On May 19, 2005, at 10:11 AM, Mark Mitchell wrote:
Nobody's objected, and it's fine by me. So, let's do it.
Ping.
I kinda wish someone would review the libjava breakage patch for
darwin...
This was already applied though not with your name on the cha
On May 19, 2005, at 10:11 AM, Mark Mitchell wrote:
Nobody's objected, and it's fine by me. So, let's do it.
Ping.
I kinda wish someone would review the libjava breakage patch for
darwin...
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01821.html
otherwise, I don't see the point in slushing to fi
On May 19, 2005, at 1:31 PM, Kaveh R. Ghazi wrote:
If you're running tests on a primary platform, and think things are
OK, please send me an email pointing at gcc-testresults mail showing
allegedly clean results for that platform *and* update:
http://gcc.gnu.org/wiki/GCC%204.1%20Slush
I ran mainli
9 May 2005 17:14:47 - 1.494
+++ index.html 19 May 2005 17:44:35 -
@@ -71,8 +71,12 @@ mission statement.
will become GCC 4.1.0 (current changes)
Branch status:
+
+ http://gcc.gnu.org/wiki/GCC%204.1%20Slush";>code slush
+ (open for bootstrap and regression fixes only).
> If you're running tests on a primary platform, and think things are
> OK, please send me an email pointing at gcc-testresults mail showing
> allegedly clean results for that platform *and* update:
>
> http://gcc.gnu.org/wiki/GCC%204.1%20Slush
I ran mainline tests checked out last night on
Richard Henderson wrote:
After three days of sequential bootstrap breakage, I'd like to propose
that mainline go into slush, wherein all these bootstrap problems, and
all the new testsuites failures get fixed. No other patches would be
allowed at all.
We'd unslush when the primary plat
> I'm not confident we know what clean results are for all the primary
> platforms, i.e. that anyone has tracked what failures are regressions and
> what aren't (which requires testing the FAILing tests with older
> compilers, not just presuming that a FAILing test not in a previous
> release isn't
On Thu, May 19, 2005 at 01:09:28AM +, Joseph S. Myers wrote:
> On Wed, 18 May 2005, Richard Henderson wrote:
>
> > After three days of sequential bootstrap breakage, I'd like to propose
> > that mainline go into slush, wherein all these bootstrap problems, and
>
On Wed, 18 May 2005, Richard Henderson wrote:
> After three days of sequential bootstrap breakage, I'd like to propose
> that mainline go into slush, wherein all these bootstrap problems, and
> all the new testsuites failures get fixed. No other patches would be
> allowed
>>>>> Richard Henderson writes:
Richard> After three days of sequential bootstrap breakage, I'd like to propose
Richard> that mainline go into slush, wherein all these bootstrap problems, and
Richard> all the new testsuites failures get fixed. No other patches wou
On Wed, May 18, 2005 at 05:31:29PM -0700, Richard Henderson wrote:
> After three days of sequential bootstrap breakage, I'd like to propose
> that mainline go into slush, wherein all these bootstrap problems, and
> all the new testsuites failures get fixed. No other patches would b
> We'd unslush when the primary platforms have clean test results.
>
> Thoughts?
Aye :)
-eric
After three days of sequential bootstrap breakage, I'd like to propose
that mainline go into slush, wherein all these bootstrap problems, and
all the new testsuites failures get fixed. No other patches would be
allowed at all.
We'd unslush when the primary platforms have clean te
80 matches
Mail list logo
