On 17.08.2009 12:00, Mikael Pettersson wrote:
On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose wrote:
On 12.08.2009 23:07, Martin Guy wrote:
On 8/12/09, Joel Sherrill wrote:
So any ACATS results from any other ARM target would be
appreciated.
I looked into gnat-arm for the new Deb
On Thu, Aug 20, 2009 at 2:33 AM, Jeff Law wrote:
> On 08/19/09 17:46, Ian Lance Taylor wrote:
>>
>> My understanding is that that scenario is supposed to not happen because
>> update_equiv_regs is only supposed to equate a register and a memory
>> location in the specific cases where that is OK. I
On Thu, Aug 20, 2009 at 3:19 AM, Albert Cohen wrote:
> Richard Guenther wrote:
>>
>> gfortran.dg/reassoc_4.f, the hottest loop from calculix.
>
> Thanks.
>
> This example is slightly different. Graphite should be able to handle it
> with loop fusion rather than pre-unrolling + cse. But I agree that
Ian Lance Taylor writes:
> Mikael Pettersson writes:
>
> > When browsing e.g. gcc-cvs via the web it used to be possible to click on a
> > newly added file and get a 'download raw' (I think it was called) option to
> > see the file without all that idiotic html formatting. That seems to be
IIRC another code that is "improved" by complete_unrolli is the polyhedron
test induct.f90. However it gives worse results for some variants
(see pr34265: induct_v2/3).
> Can't we use graphite to re-roll loops? ...
Is doing and undoing always some kind of work?
Cheers
Dominique
On Thu, Aug 20, 2009 at 11:48 AM, Dominique Dhumieres wrote:
> IIRC another code that is "improved" by complete_unrolli is the polyhedron
> test induct.f90. However it gives worse results for some variants
> (see pr34265: induct_v2/3).
>
>> Can't we use graphite to re-roll loops? ...
>
> Is doing
Jerry Quinn wrote:
> On Tue, 2009-08-18 at 08:43 -0700, Richard Henderson wrote:
>> On 08/17/2009 07:40 PM, Jerry Quinn wrote:
>>> On Mon, 2009-08-17 at 16:16 -0400, Jason Merrill wrote:
I'm not sure why GCC sources would need to mangle function-local
structs, though.
>> Would it be helpf
> That depends a bit on the compiler version and optimization level,
> but (in particular in the 3.x time frame) GCC may output assembler
> code on a function-by-function basis, without necessarily reading
> in the whole source file first.
Ok, actually it doesn't matter if it doesn't work all the
Matthias Klose wrote:
On 17.08.2009 12:00, Mikael Pettersson wrote:
On Wed, 12 Aug 2009 23:08:00 +0200, Matthias Klose wrote:
On 12.08.2009 23:07, Martin Guy wrote:
On 8/12/09, Joel Sherrill wrote:
So any ACATS results from any other ARM target would be
apprec
Richard Guenther wrote:
>> If this is not clear, I can write some pseudo-code to clarify :-).
>
> Can't we use graphite to re-roll loops? That is, compress the
> polyhedron by introducing a new parameter? But maybe I am
> not good at guessing what your initial bloat issue looks like.
>
> The re
Jerry Quinn wrote:
> On Thu, 2009-08-20 at 11:12 +0100, Dave Korn wrote:
>> Jerry Quinn wrote:
>>> Apparently my change is too naive, because the assembler doesn't like a
>>> name with '*' in it. Are there any chars that can pass muster with
>>> assemblers but not be a valid namespace identifier?
On Thu, 2009-08-20 at 11:12 +0100, Dave Korn wrote:
> Jerry Quinn wrote:
> > On Tue, 2009-08-18 at 08:43 -0700, Richard Henderson wrote:
> >> On 08/17/2009 07:40 PM, Jerry Quinn wrote:
> >>> On Mon, 2009-08-17 at 16:16 -0400, Jason Merrill wrote:
> I'm not sure why GCC sources would need to ma
On 08/19/09 18:48, Ian Lance Taylor wrote:
Jeff Law writes:
You're right. This should have been rejected by validate_equiv_mem,
but isn't because the two memory references are in different alias
sets.
You can see this in the mainline sources configured for
i686-pc-linux-gnu by compiling
On Thu, 2009-08-20 at 14:05 +0100, Dave Korn wrote:
> Jerry Quinn wrote:
> > On Thu, 2009-08-20 at 11:12 +0100, Dave Korn wrote:
> >> Jerry Quinn wrote:
>
> >>> Apparently my change is too naive, because the assembler doesn't like a
> >>> name with '*' in it. Are there any chars that can pass mus
On 08/20/09 02:45, Richard Guenther wrote:
It looks indeed bogus. Do you have a testcase at hand?
Compile the attached testcase with -O3 -mopenmp on i686-pc-linux-gnu.
Find MAIN__.omp_fn.2 in the .expand dump.
Within that function, you're looking for this sequence of insns:
;; D.3137
On Thu, Aug 20, 2009 at 3:37 PM, Jeff Law wrote:
> On 08/20/09 02:45, Richard Guenther wrote:
>>
>> It looks indeed bogus. Do you have a testcase at hand?
>>
>
> Compile the attached testcase with -O3 -mopenmp on i686-pc-linux-gnu. Find
> MAIN__.omp_fn.2 in the .expand dump.
>
> Within that funct
Jerry Quinn wrote:
>
> OK, I'm now confused. How does this dovetail with anonymous
> namespaces?
We're talking about typeinfo strings. The namespace is part of the typeinfo
name string (the so-called NTBS name), and it's the random number in the
anonymous namespace name used for these local
Dave Korn wrote:
> What I think you need to do is use an identifier for the
> anonymous namespace without an asterisk, but prefix the asterisk when
> generating the corresponding NTBS name string; then your changes to the name
> comparison routines in libsupc++ should work, but the typeinfo name st
Status
==
The 4.4 branch is open for commits under the usual release branch
rules. The timing of the 4.4.2 release (at least two months after the
4.4.1 release, at a point when there are no P1 regressions open for
the branch) has yet to be determined.
Quality Data
Priority
Paul Edwards wrote:
> > Hmm, it seems 3.2.x would *always* operate on a function-by-function
> > basis. The unit-at-a-time mode was only introduced with 3.4 (I don't
> > recall if it was already present in 3.3). I don't think there is any
> > way in 3.2.3 to check whether there is a "main" funct
> -Original Message-
> From: Lawrence Crowl [mailto:cr...@google.com]
> The problem is that gcc does support 80386. It also supports
> other processors that have less-than-complete support for
> concurrency. Just in the x86 line, we get some additional
> capability in many new laye
> Hmm, it seems 3.2.x would *always* operate on a function-by-function
> basis. The unit-at-a-time mode was only introduced with 3.4 (I don't
> recall if it was already present in 3.3). I don't think there is any
> way in 3.2.3 to check whether there is a "main" function in the file
> before it
Snapshot gcc-4.5-20090820 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090820/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Hello,
After searching this list it appears that with recent gcc (I am using gcc
4.1), C++ exception handling has zero overhead (unless an exception actually
happens)
Where can I find more information on how exception handling is done and if
this zero overhead property is always true.
I looke
SD wrote:
> Hello,
>
> After searching this list it appears that with recent gcc (I am using gcc
> 4.1), C++ exception handling has zero overhead (unless an exception actually
> happens)
>
> Where can I find more information on how exception handling is done and if
> this zero overhead propert
Dave Korn writes:
> The
> DW2 version has zero overhead in terms of execution time when no exceptions
> are thrown, but adds a noticeable amount of memory usage for the eh tables.
For the extremely picky (and who among us is not extremely picky) there
is still some overhead in the dwarf2 version
Hi all,
I saw that folks on IRC were wondering about branch commits that were
not posted to gcc-patches. I was planning to emerge from stealth mode
once the branch had something that could be useful for trunk, but
since there is interest I will post status and plans now.
Right now there are three
[Third try. Apparently the compressed dump was still too big to get through]
So I got fed up with trying to navigate gengtype maze of type_p,
pair_p and others and trying to figure out the difference between
GC_POINTED_TO and GC_USED and what is so "maybe" about
GC_MAYBE_POINTED_TO, thus I extende
28 matches
Mail list logo
