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 case
GCC community,
As some of you may know, a group met this past January in Geneva
to
discuss ways of improving GCC performance for Itanium. The group
identified three optimizations that should help significantly:
- Rotating Registers (including Swing Modulo Scheduling)
- Superblock Scheduling
On Sep 7, 2005, at 12:19 PM, Michael Tegtmeyer wrote:
This doesn't need to be that sophisticated.
So, the answer can be wrong and code generation won't be wrong? I
don't know what you mean by *could have been* accessed. I don't even
know what you mean by member.
So in this case, I do no
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 failur
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 easi
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-inval
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
On Sep 7, 2005, at 12:36 AM, Noe Aljaz ITICMN wrote:
Maybe... I think the 'big_header', which is required by template
definitions, has a big impact here. And I find it hard to believe that
excluding a big chunk of code from compilation results in no speed-up.
Even when using precompiled headers,
All of them is certainly safe, other answers require digging and thinking. A
few points to ponder might include: Do you want to know about fields that are
accessed indirectly though implicit/explicit calls? Do you want to know what
fields are accessed by the compiler without the control of the
On Sep 7, 2005, at 8:58 AM, Michael Tegtmeyer wrote:
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.
Ah, now we get to the the start of the real q
Andrew Pinski wrote:
> Does anyone know of the status of --enable-mapped-location? I tried to
> do a bootstrap and test and I got a lot of failures due to getting the
> wrong line number and file for the error message when dealing with
macros.
I took a look. The status doesn't seem to have ch
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 binut
On Wed, 2005-09-07 at 13:25 -0400, Michael Tegtmeyer wrote:
> > 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
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 cor
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 compi
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
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 yo
> 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 point
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.
"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
M-x grep access cp/*.[ch] will show you the existing methods of access
control. lookup_member would be a useful routine to set a breakpoint on and
watch how it does it as well.
Thanks for the reply, this is a static analysis pass so am I wrong in
thinking that most of the functionality provid
-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:
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 befor
> 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
> "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
Mik
> "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
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
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 detec
From: Ian Lance Taylor
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 particularly goo
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 sh
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 avail
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 th
> 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
> f
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 like
34 matches
Mail list logo
