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
Per Bothner writes:
> Andrew Haley wrote:
> > However, these fields are real, and they are used, but we shouldn't
> > output any debug info for them.
>
> Does Dwarf support "computed field offsets"? (This might be needed
> for Ada, to.) If so, the Right Thing might be to emit DIEs so gdb
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,
Andrew Haley wrote:
However, these fields are real, and they are used, but we shouldn't
output any debug info for them.
Does Dwarf support "computed field offsets"? (This might be needed
for Ada, to.) If so, the Right Thing might be to emit DIEs so gdb
can calculate the field offsets, mimicing th
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
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, and send me a message saying whether or
not there are a
> 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
I plan to create RC2 bits tomorrow.
The only PR which I currently think might merit holding up the final
release is:
20973 [4.0/4.1 Regression] kdelibs (khtml) miscompiled by reload
Michael Matz has attached a possible reload patch to the PR. Any comments?
I'm not going to wait very long even fo
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
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 some of the C++ issues, but he's in Lillehammer this week
for the ISO meeting.
64 matches
Mail list logo
