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
in the
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
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
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, I'll
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
at it
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 tonight.
I took
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 like Andrew,
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:
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:
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 being
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.
There's a
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 for
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
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 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. Do you
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
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 separately.
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
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
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/msg00803.html
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,
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
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 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(TFmode),
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~
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 work
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 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 broke it.
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
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 a
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:
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
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
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...
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
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,
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.
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.
Richard
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 unslush
40 matches
Mail list logo
