Simply put, it's time for another GCC 4.0.x release.
There are 48 critical bugs open against 4.0.1 and some nearly 200
regressions. I've not done a complete triage, so I can't say how many
of these might be incorrectly targeted. Fewer than 20 are wrong-code,
which is still more than I'd
Normal compiles instantiate items as determined by the
database. It is a known waste of compile time to not so
instantiate such things, as we know they will be
instantiated. So, the entire concept doesn't make much sense
to me, unless you only are only interested in the speedup
from
Since August 21st, when I sent my last status report, we've reduce the
number of bugs targeted at 4.1 from 271 to 250; about a bug a day. 77
of these bugs are wrong-code, ice-on-valid-code, or rejects-valid, down
from 91. So, that suggests that the net progress is mostly coming from
fixing
Further to Eric's good advice:
Do you already have access to a mips64 version of glibc? (You said in
your message that you'd tried a native build, but I wasn't sure whether
that was using a 32-bit OS or a 64-bit OS)
It's tricky to build a toolchain and glibc in tandem (i.e. when neither
is
I don't have a mips64 version of glibc, I'm having to
build the entire toolchain from the ground up. (Yuck.)
I'm trying to build the entire toolchain as 64-bit
native, which is adding to my problems.
(Crosstool, for example, only supports 32-bit MIPS -
and even then the build matrix is a pretty
From: Ian Lance Taylor ian@airs.com
To: Yao qi [EMAIL PROTECTED]
CC: gcc@gcc.gnu.org
Subject: Re: var_args for rs6000 backend
Date: 06 Sep 2005 11:05:38 -0700
Yao qi [EMAIL PROTECTED] writes:
These are partially documented in gcc/doc/tm.texi. Unfortunately the
documentation is not
There's no special freeze for the 4.0 branch at this point; we'll leave
it in regression-fixes only mode. The branch will freeze when I create
the first release candidate.
Some of your C++ fixes have been quite invasive. Maybe it's too much
haste to spin the rc before the bugs can be
Planned vectorization enhancements for 4.2:
1. Recognize reduction patterns (Dorit).
Some computations have specialized target support and can be
vectorized more efficiently if the computation idiom is recognized and
vectorized as a whole. This is especially true to idioms that involve
Jonathan == Jonathan Day [EMAIL PROTECTED] writes:
Jonathan Hi, I am trying to compile a toolchain for a Broadcom SB1
Jonathan processor in big-endian mode with a host Operating System
Jonathan of Linux. (The SB1 is a MIPS64, but there is also a
Jonathan specific SB1 target.) So far, I'm
Mike == Mike Stump [EMAIL PROTECTED] writes:
Mike On Sep 6, 2005, at 6:16 PM, Gabriel Dos Reis wrote:
wrong-code generation that was fixed.
Mike Customers validate their app and are `happy' with the code
Mike generation, so this appears to not be a real an issue. Failure
Mike to compile
Since August 21st, when I sent my last status report, we've reduce the
number of bugs targeted at 4.1 from 271 to 250; about a bug a day.
On the gcc home page, we have a (now obsolete) link to the latest
status. We also have a link to the definition of stage 3. Could we
add a direct link to
Paolo Bonzini wrote:
There's no special freeze for the 4.0 branch at this point; we'll
leave it in regression-fixes only mode. The branch will freeze when I
create the first release candidate.
Some of your C++ fixes have been quite invasive. Maybe it's too much
haste to spin the rc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I got an unexpected link behaviour linking statically.
linking dynamically:
g++ -Wall -g0 -O3 -o batch_mesh_1 batch_mesh_1.o
- -L/raid/tecosim/it/devel/install-test/hp/lib -ltecosim -lteclic
everything works fine and ldd batch_mesh_1 gives:
Yao Qi qi [EMAIL PROTECTED] writes:
New data types were added into GCC as well as new modes.
It might help if you give a brief overview of what you are trying to
do (maybe you already have, and I forgot). Also, I assume you are
working with mainline gcc.
Argument
passing and
return value
On Sep 7, 2005, at 11:21 AM, Mark Mitchell wrote:
Paolo Bonzini wrote:
There's no special freeze for the 4.0 branch at this point; we'll
leave it in regression-fixes only mode. The branch will freeze when
I create the first release candidate.
Some of your C++ fixes have been quite invasive.
Actually, that was the real question, nothing more. I need to be able to
determine what member fields of an object passed to a function are visible
to that function during an optimization pass. Is there existing
functionality somewhere to do that?
All of them, assuming you have a pointer
There was also a PowerPC NT ABI at one point, but since Windows NT on
PowerPC was stillborn, it was removed.
My point was if you are working on the ABI functions, you need to make
sure that the other ABIs (AIX, Darwin) don't get broken by any changes
you make (presumably you will make sure that
Jonathan Day [EMAIL PROTECTED] writes:
My question is simple enough - has anyone built a
toolchain for a MIPS64-Linux-GNU target?
Yes, I did, last year.
But I did it through a tedious iterative process--build the binutils,
build the compiler until it fails building libgcc, install parts of
Ian Lance Taylor writes:
Jonathan Day [EMAIL PROTECTED] writes:
My question is simple enough - has anyone built a
toolchain for a MIPS64-Linux-GNU target?
Yes, I did, last year.
But I did it through a tedious iterative process--build the binutils,
build the compiler until it
If you just have a regular object passed by value, the fields accessible
are those in TYPE_FIELDS of the type of the object, and those fields
reachable through types in the TYPE_BINFOS (i don't remember whether we
represent access control in binfos)
Ah, I guess I am not actually wording this
Andrew Haley wrote:
Ian Lance Taylor writes:
Jonathan Day [EMAIL PROTECTED] writes:
My question is simple enough - has anyone built a
toolchain for a MIPS64-Linux-GNU target?
Yes, I did, last year.
But I did it through a tedious iterative process--build the binutils,
David Daney wrote:
Ian Lance Taylor writes:
Jonathan Day [EMAIL PROTECTED] writes:
My question is simple enough - has anyone built a
toolchain for a MIPS64-Linux-GNU target?
Yes, I did, last year.
But I did it through a tedious iterative process--build the
binutils,
build
On 7 Sep 2005, Gabriel Dos Reis wrote:
Mike Stump [EMAIL PROTECTED] writes:
| I'll echo the generalized request that we try and avoid tightenings
| on other than x.y.0 releases.
I hear you. In this specific case, it worths remembering people that
the issue is not just an accept-invalid that
Kai Ruottu wrote:
How one gets the first toolchain made shouldn't have the importance
many people think it has... My opinion (clashing badly with Dan's) is
that the first build has no importance at all, if one knows the basics
for Linux, for compiling and for other newbie-level things, one
On Mon, 2005-09-05 at 17:39 -0400, Richard Kenner wrote:
Suppose lhs_vr is [64,64] and vr_result is ~[0,0]. It would seem
that the code near the end of this function will malfunction.
Shouldn't the test be that both lhs_vr *and* vr_result are VR_RANGE?
This is causing an ACATS failure in
Andrew Pinski wrote:
But there are still issues.
PR 23691 is one of them which beaks boost.
I wasn't aware that there were still issues. Please assign me to PRs
that represent things I've broken; I'll fix them, or at least explicitly
unassign myself if I feel unfairly blamed.
In any
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-07
07:27 ---
CRIS is not a primary target. Removing target milestone.
--
What|Removed |Added
Target
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
07:36 ---
Subject: Bug 19269
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-07 07:36:12
Modified files:
gcc/fortran: ChangeLog simplify.c
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-07
07:45 ---
Java bugs are not release-critical; removing target milestone.
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net
|dot org |dot au
Status|NEW
--- Additional Comments From charlet at gcc dot gnu dot org 2005-09-07
09:00 ---
I'll take care of it.
Arno
--
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-07
09:26 ---
I agree with the analysis and the fix. Care to submit the patch to gcc-patches?
Do you have a copyright assignment on file with the FSF? If not the patch may
be simple enough to be accepted regardless of
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-07
09:59 ---
Long-standing problem in Gigi, will be fixed by the next push from AdaCore.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22418
--- Additional Comments From goweol at gmail dot com 2005-09-07 10:20
---
After reported this bug, I built several m6811-elf-gcc compiler.
Those are 20050318, 20050426, 20050516, and 20050907 version.
At this time, 20050318 and 20050426 generates ICE.
But 20050516 and 20050907 version
--- Additional Comments From pcarlini at suse dot de 2005-09-07 10:23
---
Not a regression, in any sense. Given that, and the almost-deprecated status
of vectorbool, better not touching this for the current release branch. Fixed
for 4.1.0, anyway.
--
What|Removed
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07
10:37 ---
Is this still a problem? The other two testcases seem to work now.
--
What|Removed |Added
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07
10:40 ---
Fixed by the partial patch for 19269
--
What|Removed |Added
OtherBugsDependingO|
--
Bug 19276 depends on bug 21825, which changed state.
Bug 21825 Summary: [4.0/4.1 Regression] 2D array initialization with reshape
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21825
What|Old Value |New Value
--- Additional Comments From pcarlini at suse dot de 2005-09-07 10:42
---
Not a but, this behavior is intended and correct. According to the Standard
(Table 57), the stdio equivalent for hex formatting will be exactly %x (or %X).
Then try printf(%x, -1) on your machine.
--
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07
10:45 ---
Fixed by the same patch as 15326.
--
What|Removed |Added
BugsThisDependsOn|
--- Additional Comments From pcarlini at suse dot de 2005-09-07 10:55
---
Fixed for 4.1.0.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
11:58 ---
Subject: Bug 23747
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-07 11:57:47
Modified files:
gcc: ChangeLog
gcc/config/m32r:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
12:05 ---
Subject: Bug 23747
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-07 12:04:42
Modified files:
gcc:
Setting java.library.path on the gij command line should set the module loader
path to the given argument. Currently an attempt is made to do this in
natSystemProperties.cc:
// If java.library.path is set, tell libltdl so we search the new
// directories as well. FIXME: does this work
If java.library.path was not specified on the command line its value should
default to the contents of LD_LIBRARY_PATH on GNU/Linux systems or
LTDL_SHLIBPATH_VAR generally.
--
Summary: java.library.path should default to value of environment
variable specified by
--- Additional Comments From fitzsim at redhat dot com 2005-09-07 12:36
---
Filed two new bugs for the remaining java.library.path issues:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23761
and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23762
I'm closing this bug.
--
Showcase: compile exectest.c, run test.java calling 'exectest'
Runtime.exec() seems to pass down some strange signal configuration to child
processes in GCC =4.0.0. When run from test.java the exectest.c parent process
does never get CHLD signals - they seem to get blocked (as I've seen the
--- Additional Comments From aeby at graeff dot com 2005-09-07 13:17
---
Created an attachment (id=9686)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9686action=view)
Execs exectest and demonstrates how it hangs
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23763
--- Additional Comments From aeby at graeff dot com 2005-09-07 13:18
---
Created an attachment (id=9687)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9687action=view)
Sample program that hangs when executed via Runtime.exec()
--
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-07
13:20 ---
This is not a problem with dynamic stack allocation, but rather with the
instrumentation code.
The following diagram is supposed to show what the V4 stack layout looks like
just after the function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
13:23 ---
Fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-09-07
13:36 ---
Subject: Re: CCP not fully propagating
constants
On Wed, 2005-09-07 at 04:19 +, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07
13:43 ---
It's not clear who's on the hook to the fix the transpose() call.
I'll unassign myself in the meantime.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
14:03 ---
Fixed by:
2005-09-07 Andreas Krebbel [EMAIL PROTECTED]
* reload1.c (fixup_eh_region_note): Remove assertion.
(fixup_abnormal_edges): Reverted removal of call to
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662
--
What|Removed |Added
Target Milestone|--- |3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6181
--
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5942
--
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2956
--
What|Removed |Added
Target Milestone|--- |3.0.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1392
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23746
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23565
--
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1391
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21255
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19481
--
What|Removed |Added
Keywords||build, ice-on-valid-code
Summary|pt.c:9462: ICE: in |[4.1 Regression] pt.c:9462:
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23661
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23561
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23607
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23475
--- Additional Comments From ghazi at gcc dot gnu dot org 2005-09-07 14:18
---
Updated patch for mainline here:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00302.html
--
What|Removed |Added
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-07
14:39 ---
Simplified testcase. This bug is probably a WONTFIX.
int bar (int *);
int foo (void)
{
int x;
__builtin_memset (x, 0, 32);
return bar (x);
}
--
What|Removed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
15:25 ---
Subject: Bug 22555
CVSROOT:/cvs/gcc
Module name:gcc
Branch: improved-aliasing-branch
Changes by: [EMAIL PROTECTED] 2005-09-07 15:25:13
Modified files:
gcc
Trying to compile the following code on a FreeBSD 5.4 machine, using GCC
4.0.1
# 1 Test.cpp
# 0 built-in
# 1 command line
# 1 Test.cpp
class OutStream
{
public:
OutStream();
};
inline OutStream operator( OutStream output, const int value )
{
return output;
}
class Client
{
public:
--- Additional Comments From fitzsim at redhat dot com 2005-09-07 15:48
---
I filed a bug against GTK:
http://bugzilla.gnome.org/show_bug.cgi?id=315462
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21598
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
15:49 ---
Not a bug as you cannot bind a rvalue to the reference type.
Basicially what you have is:
int g(void);
void h(int);
void j(void)
{
h(g());
}
And that is invalid. You can bind a rvalue to a const
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07
15:59 ---
Testing a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
[EMAIL PROTECTED]:~/src/tests cat pr16404.f90
REAL, TARGET :: B(2,2)
common x/b/
B = 1.
END
[EMAIL PROTECTED]:~/src/tests ../gcc/build/gcc/f951 pr16404.f90
MAIN__
pr16404.f90:3: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if
--- Additional Comments From x at xman dot org 2005-09-07 16:03 ---
The ANSI definition for %x (or %X) only covers unsigned integers. Surely then
doing hex formatting on a signed integer would at the very least be undefined
behavior.
--
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-07
16:07 ---
Can someone ping this patch on the gcc-patches ml?
--
What|Removed |Added
Last
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07
16:07 ---
Confirmed, backtrace:
#0 0x080a2406 in translate_common (common=0x96d29b8, var_list=Variable
var_list is not
available.
) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/trans-common.c:879
#1
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-07 16:09
---
(In reply to comment #16)
Since number 2 is already reported, we only have 3 and 6 left:
I have a patch for 3 and will try to sort out 6 (+pr21986) as soon as I have a
moment.
--
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-07 16:17
---
Reduced testcase:
common /b/
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23765
--- Additional Comments From pcarlini at suse dot de 2005-09-07 16:28
---
(In reply to comment #7)
The ANSI definition for %x (or %X) only covers unsigned integers. Surely then
doing hex formatting on a signed integer would at the very least be undefined
behavior.
Yes, you have a
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-07
16:30 ---
Subject: Bug 23358
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-09-07 16:30:38
Modified files:
libstdc++-v3 :
--- Additional Comments From pcarlini at suse dot de 2005-09-07 16:32
---
Fixed for 4.0.2 too.
--
What|Removed |Added
Target Milestone|4.1.0 |4.0.2
--- Additional Comments From pcarlini at suse dot de 2005-09-07 16:51
---
(In reply to comment #8)
Yes, you have a point that the mapping prescribed by the ISO/IEC Standards is
not very precise, because, strictly speaking, the C Standard speaks only about
unsigned int and the C++
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-07
16:58 ---
Hmm. I supposed I'd better check. Is the following code
also valid:
program main
implicit none
real, dimension (:), pointer :: x
x = null()
x = test ()
contains
function test
real,
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-07 17:02
---
Patch here: http://gcc.gnu.org/ml/fortran/2005-09/msg00089.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23765
The following code does not compile. According to the compiler,
't' is overloaded ambiguously.
#include vector
struct T {
typedef std::vectorint Vector;
typedef Vector::iterator iterator;
typedef Vector::const_iterator const_iterator;
int t( iterator f) { return *f; }
--- Additional Comments From tobi at gcc dot gnu dot org 2005-09-07 17:04
---
I don't have the standard at hand, but both the Intel and the Portland Group
compiler accept this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23373
--- Additional Comments From afra at cs dot stanford dot edu 2005-09-07
17:04 ---
Created an attachment (id=9688)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9688action=view)
complete program showing bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
--
What|Removed |Added
Component|c++ |libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23767
--- Additional Comments From richard at codesourcery dot com 2005-09-07
17:07 ---
Subject: Re: Functions returning pointers with pointer argument
tobi at gcc dot gnu dot org [EMAIL PROTECTED] writes:
I don't have the standard at hand, but both the Intel and the Portland Group
--
What|Removed |Added
Known to fail||3.0.4 3.3.3 3.4.0 4.0.0
Known to work||2.95.3
--
What|Removed |Added
Keywords|missed-optimization |diagnostic
Last reconfirmed|2005-05-16 02:30:28 |2005-09-07 17:43:18
date|
--- Additional Comments From nico at cam dot org 2005-09-07 18:24 ---
I just tested with HEAD today and the problem doesn't appear to be there any
longer. Therefore gcc 4.1.0 should be OK.
--
What|Removed |Added
The JCE spec for Cipher.doFinal states:
Upon finishing, this method resets this cipher object to the state it was in
when previously initialized via a call to init. That is, the object is reset and
available to encrypt or decrypt (depending on the operation mode that was
specified in the call to
--
What|Removed |Added
Keywords||alias
Last reconfirmed|2005-07-04 21:36:12 |2005-09-07 18:35:18
date|
--
What|Removed |Added
Component|libgcj |classpath
Product|gcc |classpath
Version|4.0.1
--
What|Removed |Added
CC||bug-classpath at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23768
1 - 100 of 169 matches
Mail list logo
