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
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 fixed. No other patches would be
>> allowe
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
On Thu, May 19, 2005 at 10:11:54AM -0700, Mark Mitchell 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%2
> 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 platforms have c
> 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
> > all the new testsuites failur
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 at all.
>
> We'd unslus
> 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 would be
Richard> allowed at all.
R
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 be
> allowed at
> 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 test results.
Thou
54 matches
Mail list logo
