On Wed, 2005-04-20 at 01:18, Josh Conner wrote:
> On Apr 18, 2005, at 3:12 PM, Julian Brown wrote:
>
> > Results for arm-none-elf, cross-compiled from i686-pc-linux-gnu
> > (Debian)
> > for C and C++ are here:
> >
> > http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01301.html
> >
> > Relative to
On 19/04/2005, at 6:24 AM, Andrew Haley wrote:
Geoffrey Keating writes:
Mark Mitchell <[EMAIL PROTECTED]> writes:
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
As before, I'd very much appreciate it if people would test these
bits
on primary and secondary platforms,
On Apr 18, 2005, at 3:12 PM, Julian Brown wrote:
Results for arm-none-elf, cross-compiled from i686-pc-linux-gnu
(Debian)
for C and C++ are here:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01301.html
Relative to RC1, there are several new tests which pass, and:
g++.dg/warn/Wdtor1.C (test fo
Andrew Haley wrote:
At compile time we don't know the field offset of fields that we
inherit, because it can change at runtime. So, we don't set the
FIELD_OFFSET, and that is is why dbxout is aborting.
OK. I certainly can't claim that this aspect of the GCC IR is
particularly well specified. Fo
Joseph S. Myers wrote:
Results for hppa2.0w-hp-hpux11.11, no regressions:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01379.html
Thanks; posted on the Wiki.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Joe Buck wrote:
On Mon, Apr 18, 2005 at 07:44:03AM -0700, Mark Mitchell wrote:
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
x86_64-unknown-linux-gnu results (for RHEL v3) are at
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01333.html
The failures are almost all
> I don't recall seeing it, but then I get a lot of mail. Sorry if I lost
> it.
No problem, I only wanted to check.
> But if these failures are important, shouldn't we be recommending the
> second patch to users?
It's 64-bit STABS and nobody uses 64-bit STABS (as generated by GCC).
As an altern
On Tue, Apr 19, 2005 at 09:23:17PM +0200, Eric Botcazou wrote:
> > Yes, you sent me a message before when I couldn't build at all, which I
> > applied, but you pointed me to a different patch:
>
> I was talking about a second message.
I don't recall seeing it, but then I get a lot of mail. Sorry
> Yes, you sent me a message before when I couldn't build at all, which I
> applied, but you pointed me to a different patch:
I was talking about a second message.
> If an additional patch is needed, install/specific.html should be updated,
> and perhaps a single patch that does the whole job sho
On Mon, Apr 18, 2005 at 07:44:03AM -0700, Mark Mitchell wrote:
>
> RC2 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
x86_64-unknown-linux-gnu results (for RHEL v3) are at
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01333.html
The failures are almost all rel
Results for hppa2.0w-hp-hpux11.11, no regressions:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01379.html
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla ass
Tom Tromey writes:
> > "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>
> Andrew> At compile time we don't know the field offset of fields that we
> Andrew> inherit, because it can change at runtime. So, we don't set the
> Andrew> FIELD_OFFSET, and that is is why dbxout is aborting
> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
Andrew> At compile time we don't know the field offset of fields that we
Andrew> inherit, because it can change at runtime. So, we don't set the
Andrew> FIELD_OFFSET, and that is is why dbxout is aborting.
Andrew> All I want is for FIELD
Andrew Haley writes:
> Mark Mitchell writes:
> >
> > The C++ front-end (and probably the C front-end) strips
> > zero-width (and possibly unnamed) bitfields after class layout.
> > This can be justified in that those bitfields only affect
> > layout; one doesn't need the middle-end to c
On Tue, Apr 19, 2005 at 04:20:19PM +, Joseph S. Myers wrote:
> On Mon, 18 Apr 2005, Joe Buck wrote:
>
> > It appears the bug is because there's a libiconv.so in /usr/local/lib on
> > that machine, with headers in /usr/local/include, but /usr/local/lib isn't
> > in my LD_LIBRARY_PATH. configur
Andrew Haley wrote:
Do you mean running through the struct removing such fields from the
list? OK, I can do that.
Yes.
> So, I would suggest fixing this in the Java front end.
I'll see if I can find the C++ front end code you refer to and use it
as a reference.
Look in class.c for remove_zero_wid
On Mon, 18 Apr 2005, Joe Buck wrote:
> It appears the bug is because there's a libiconv.so in /usr/local/lib on
> that machine, with headers in /usr/local/include, but /usr/local/lib isn't
> in my LD_LIBRARY_PATH. configure finds the declaration and assumes it
> can call the function. Sorry, I d
The C++ front-end (and probably the C front-end) strips zero-width
(and possibly unnamed) bitfields after class layout. This can be
justified in that those bitfields only affect layout; one doesn't need
the middle-end to copy them around, etc. So, you could probably fix
this i
On Tue, Apr 19, 2005 at 08:12:05AM +0200, Eric Botcazou wrote:
> > For sparc-sun-solaris2.8, I get a failure when building the Java compiler,
> > but I may be doing something wrong, as I usually avoid the Java build
> > on Solaris (since it takes most of a day to build and test).
>
> Known glitch.
Joe Buck wrote:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01307.html
Thanks.
For sparc-sun-solaris2.8, I get a failure when building the Java compiler,
but I may be doing something wrong, as I usually avoid the Java build
on Solaris (since it takes most of a day to build and test).
Thanks.
Mark Mitchell writes:
> Andrew Haley wrote:
> > Geoffrey Keating writes:
> > > Mark Mitchell <[EMAIL PROTECTED]> writes:
> > >
> > > > RC2 is available here:
> > > >
> > > > ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
> > > >
> > > > As before, I'd very much appreciate
Eric Botcazou wrote:
SPARC/Solaris is OK:
Thanks; I've added your information to the Wiki.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Geoffrey Keating wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
As before, I'd very much appreciate it if people would test these bits
on primary and secondary platforms, post test results with the
contrib/test_summary
Andrew Haley wrote:
Geoffrey Keating writes:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> > RC2 is available here:
> >
> > ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
> >
> > As before, I'd very much appreciate it if people would test these bits
> > on primary and secondary
James E Wilson wrote:
commented onMark Mitchell wrote:
The changes that I anticipate between now and the final release are
(a) documentation changes, (b) a patch for 20991, and (c) a possible
patch for 20973. Other than that, I will only consider patches that
fix egregious problems, like a fail to
Richard Sandiford wrote:
Results for mips-elf are here:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01331.html
and look good. No regressions.
Thanks; added to the Wiki.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ppc-linux 32-bit.
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01370.html
Andreas
Results for i686-pc-cygwin (c, c++, gfortran, objc) are here:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01363.html
No regressions for c, c++, gfortran relative to RC1.
There are several new tests, which all pass, and one less failed test in
libstdc++:
26_numerics/cmath/c99_classification_m
Geoffrey Keating writes:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> > RC2 is available here:
> >
> > ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
> >
> > As before, I'd very much appreciate it if people would test these bits
> > on primary and secondary platforms, post tes
commented onMark Mitchell wrote:
The changes that I anticipate between now and the final release are
(a) documentation changes, (b) a patch for 20991, and (c) a possible
patch for 20973. Other than that, I will only consider patches that
fix egregious problems, like a fail to bootstrap on a primar
Mark Mitchell <[EMAIL PROTECTED]> writes:
> RC2 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
>
> As before, I'd very much appreciate it if people would test these bits
> on primary and secondary platforms, post test results with the
> contrib/test_summary script, an
> For sparc-sun-solaris2.8, I get a failure when building the Java compiler,
> but I may be doing something wrong, as I usually avoid the Java build
> on Solaris (since it takes most of a day to build and test).
Known glitch. You have to find out why configure thinks you have libiconv
installed
On Apr 18, 2005, at 9:07 PM, Geoffrey Keating wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
As before, I'd very much appreciate it if people would test these bits
on primary and secondary platforms, post test results w
Mark Mitchell <[EMAIL PROTECTED]> writes:
> RC2 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
>
> As before, I'd very much appreciate it if people would test these bits
> on primary and secondary platforms, post test results with the
> contrib/test_summary script,
On Mon, Apr 18, 2005 at 05:13:33PM -0700, Joe Buck wrote:
> [ solaris failure building Java compiler ]
> It appears the bug is because there's a libiconv.so in /usr/local/lib on
> that machine, with headers in /usr/local/include, but /usr/local/lib isn't
> in my LD_LIBRARY_PATH. configure finds th
> Joe> For sparc-sun-solaris2.8, I get a failure when building the Java
> compiler,
> Joe> but I may be doing something wrong, as I usually avoid the Java build
> Joe> on Solaris (since it takes most of a day to build and test). The message
> Joe> is
>
> Joe> java/parse.o(.text+0x16cc): In func
On 2005-04-18, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
> RC2 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
>
> As before, I'd very much appreciate it if people would test these bits
> on primary and secondary platforms, post test results with the
> contrib/test_su
c,ada are clean on x86 and x86_64 linux.
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01311.html
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01313.html
Laurent
On Mon, Apr 18, 2005 at 07:44:03AM -0700, Mark Mitchell wrote:
>
> RC2 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
>
> As before, I'd very much appreciate it if people would test these bits
> on primary and secondary platforms, post test results with the
> contr
> I'm not going to wait very long even for this bug, though. Instead, I'm
> going to get 4.0.0 out the door, and move on to 4.0.1, sticking as close
> to the announced schedule as possible.
FWIW the recent Java failures have been fixed (thanks to the Java hackers!) on
SPARC, so the 4.0.0pre comp
On Thursday 14 April 2005 21:05, Mark Mitchell wrote:
> > Could you add http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01107.html
> > to your list? If the patch is OKed by rth (ping! :-), it would fix a
> > -fPIC ICE regression on IA32 and AMD64.
>
> So added. Will you please let me know if the pat
Richard Sandiford wrote:
Mark,
I tried running some MIPS16 tests against RC1 and found a regression
from 3.4. The problem is the following hack in mips.h:
/* When generating mips16 code we want to put the jump table in th
Joel Sherrill <[EMAIL PROTECTED]> wrote:
I know I asked late in the process but this fix for a m68k/coldfire
failure just showed up:
[Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391
Any chance at it getting considered?
This is OK if approved for mainline by a 68K mainta
Steven Bosscher wrote:
On Tuesday 12 April 2005 19:59, Mark Mitchell wrote:
Therefore, I'm going to allow some of the queued patches into 4.0 at
this time. If your patch isn't on this list, but is here:
http://gcc.gnu.org/wiki/Last-Minute%20Requests%20for%204.0.0
I'm still considering it. I'll le
Richard Sandiford wrote:
Richard Sandiford <[EMAIL PROTECTED]> writes:
Mark,
I tried running some MIPS16 tests against RC1 and found a regression
from 3.4. The problem is the following hack in mips.h:
[...]
The patch reduces the number of mips64 {-mips16}{-EL,-EB} C failures
from 203 to 58 with no
Richard Sandiford <[EMAIL PROTECTED]> writes:
> Mark,
>
> I tried running some MIPS16 tests against RC1 and found a regression
> from 3.4. The problem is the following hack in mips.h:
> [...]
> The patch reduces the number of mips64 {-mips16}{-EL,-EB} C failures
> from 203 to 58 with no regression
On Wed, Apr 13, 2005 at 12:37:00PM -0700, Mark Mitchell wrote:
> >>Sadly, it's become clear there's going to have to be a second release
> >>candidate. In particular, there are some wrong-code bugs that are popping
> >>up on real packages on primary platforms. Jason Merill is looking into
> >>som
Jason Merrill wrote:
On Tue, 12 Apr 2005 10:59:42 -0700, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Sadly, it's become clear there's going to have to be a second release
candidate. In particular, there are some wrong-code bugs that are popping
up on real packages on primary platforms. Jason Merill
Richard Sandiford <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
> > Richard Sandiford <[EMAIL PROTECTED]> writes:
> >> Huh. For the record: it can't. get_attr_length() returns 0
> >> for ADDR_VECs regardless of JUMP_IN_TEXT_SECTION. I'll update
> >> the comment when applying the bug-f
On Tue, Apr 12, 2005 at 10:59:42AM -0700, Mark Mitchell wrote:
> I don't have a date for RC2 yet; that will depend in part on when Jason
> is able to fix the C++ issues. However, I would certainly hope that we
> could get it done shortly.
FYI, I have bootstrapped/regtested 4.0 RC1 with:
> Here
On Tue, 12 Apr 2005 10:59:42 -0700, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Sadly, it's become clear there's going to have to be a second release
> candidate. In particular, there are some wrong-code bugs that are popping
> up on real packages on primary platforms. Jason Merill is looking int
Joel Sherrill <[EMAIL PROTECTED]> wrote:
> I know I asked late in the process but this fix for a m68k/coldfire
> failure just showed up:
>
> [Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391
>
> Any chance at it getting considered?
This patch was approved by Roger Sa
Ian Lance Taylor writes:
> Richard Sandiford <[EMAIL PROTECTED]> writes:
>> Huh. For the record: it can't. get_attr_length() returns 0
>> for ADDR_VECs regardless of JUMP_IN_TEXT_SECTION. I'll update
>> the comment when applying the bug-fix patch to mainline.
>
> shorten_branches handles JUMP_T
Richard Sandiford <[EMAIL PROTECTED]> writes:
> Huh. For the record: it can't. get_attr_length() returns 0
> for ADDR_VECs regardless of JUMP_IN_TEXT_SECTION. I'll update
> the comment when applying the bug-fix patch to mainline.
shorten_branches handles JUMP_TABLES_IN_TEXT_SECTION correctly.
Richard Sandiford <[EMAIL PROTECTED]> writes:
> PS. mips.c has the following
>
>
> /* Return the length of instruction INSN.
>
>??? MIPS16 switch tables go in .text, but we don't define
>JUMP_TABLES_IN_TEXT_SECTION
Mark Mitchell wrote:
Sadly, it's become clear there's going to have to be a second release
candidate. In particular, there are some wrong-code bugs that are
popping up on real packages on primary platforms.
I think there is a case for considering the bug discussed in this thread
release-critical
Mark,
I tried running some MIPS16 tests against RC1 and found a regression
from 3.4. The problem is the following hack in mips.h:
/* When generating mips16 code we want to put the jump table in the .text
section. In
I know I asked late in the process but this fix for a m68k/coldfire
failure just showed up:
[Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391
Any chance at it getting considered?
Thanks.
--joel
Mark Mitchell wrote:
Sadly, it's become clear there's going to have to be a s
On Tuesday 12 April 2005 19:59, Mark Mitchell wrote:
> Therefore, I'm going to allow some of the queued patches into 4.0 at
> this time. If your patch isn't on this list, but is here:
>
> http://gcc.gnu.org/wiki/Last-Minute%20Requests%20for%204.0.0
>
> I'm still considering it. I'll let you know
59 matches
Mail list logo
