the efficiency
of `task' directives.
https://github.com/laysakura/GCC-OpenMP-Speedup/raw/9636d281663a8a7857efd38700c82486ff12ae7b/data/20110427-101530-tuna-protein.eps.png
https://github.com/laysakura/GCC-OpenMP-Speedup/raw/9636d281663a8a7857efd38700c82486ff12ae7b/data/20110427-101530-tuna-fft.eps.pn
2011/4/27 Dimitrios Apostolou :
> * ggc_internal_alloc_stat() or maybe implementing proper memory management
> instead of garbage collection, for hottest caller
This one can easily take much more time than three months. I've been
working in this area, right now I'm working on allocating RTL outsid
Michael Witten writes:
> I am intending to send them again to the proper list; is this
> considered the correct move now that the patches have been sent here?
Yes.
Ian
Mohammad Masood Masaeli writes:
> Hello, I'm studying the code of GCC to now how does it work and some
> other purposes...
> Can anyone tell me how does its error recovery work?
> I think it is something near to Panic method, but I'm not sure and no
> documents exist about it!
What kind of error
On 28 April 2011 01:03, Jonathan Wakely wrote:
> On 28 April 2011 00:56, Michael Witten wrote:
>> On Wed, Apr 27, 2011 at 18:50, Jonathan Wakely wrote:
>>> You also need to explain the reason for your patches.
>>>
>>> http://gcc.gnu.org/contribute.html#patches
>>>
>>> 1 and 2 might be self-explana
On 28 April 2011 00:56, Michael Witten wrote:
> On Wed, Apr 27, 2011 at 18:50, Jonathan Wakely wrote:
>> You also need to explain the reason for your patches.
>>
>> http://gcc.gnu.org/contribute.html#patches
>>
>> 1 and 2 might be self-explanatory, but what are 3 and 4 for? Why are
>> your change
On Wed, Apr 27, 2011 at 18:48, Michael Witten wrote:
> On Wed, Apr 27, 2011 at 18:42, Jonathan Wakely wrote:
>> On 28 April 2011 00:32, Michael Witten wrote:
>>> See the following emails for a few inlined patches
>>> to /trunk/gcc/doc/extend.texi:
>>>...
>>
>> Patches should go to gcc-patches, no
On Wed, Apr 27, 2011 at 18:50, Jonathan Wakely wrote:
> You also need to explain the reason for your patches.
>
> http://gcc.gnu.org/contribute.html#patches
>
> 1 and 2 might be self-explanatory, but what are 3 and 4 for? Why are
> your changes useful?
Thank you for the help; however, I believe
On 28 April 2011 00:48, Michael Witten wrote:
> On Wed, Apr 27, 2011 at 18:42, Jonathan Wakely wrote:
>> On 28 April 2011 00:32, Michael Witten wrote:
>>> See the following emails for a few inlined patches
>>> to /trunk/gcc/doc/extend.texi:
>>>...
>>
>> Patches should go to gcc-patches, not this
On Wed, Apr 27, 2011 at 18:42, Jonathan Wakely wrote:
> On 28 April 2011 00:32, Michael Witten wrote:
>> See the following emails for a few inlined patches
>> to /trunk/gcc/doc/extend.texi:
>>...
>
> Patches should go to gcc-patches, not this list.
>
> http://gcc.gnu.org/lists.html
>
I apologize!
> However, the same effect of applying this patch can be produced by running
> the following commands on revision 172911 ...
That's not exactly correct; it is naturally assumed that the previous patches:
[1] Docs: extend.texi: Add missing semicolon for consistency
[2] Docs: extend.texi: Remov
On 28 April 2011 00:32, Michael Witten wrote:
> See the following emails for a few inlined patches
> to /trunk/gcc/doc/extend.texi:
>
> [1] Docs: extend.texi: Add missing semicolon for consistency
> [2] Docs: extend.texi: Remove trailing blanks from lines
> [3] Docs: extend.texi: Rearrange nodes
The arrangement performed in the previous patch left the text in
somewhat of an inconsistent state; this returns the flow of concepts
to something more sane.
---
trunk/gcc/doc/extend.texi | 53 +++-
1 files changed, 32 insertions(+), 21 deletions(-)
diff
sed -i "s/[ $(printf '\t')]\{1,\}\$//" trunk/gcc/doc/extend.texi
---
trunk/gcc/doc/extend.texi | 82 ++--
1 files changed, 41 insertions(+), 41 deletions(-)
diff --git a/trunk/gcc/doc/extend.texi b/trunk/gcc/doc/extend.texi
index c154958..cdbf69f 100644
---
trunk/gcc/doc/extend.texi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/trunk/gcc/doc/extend.texi b/trunk/gcc/doc/extend.texi
index eddff95..c154958 100644
--- a/trunk/gcc/doc/extend.texi
+++ b/trunk/gcc/doc/extend.texi
@@ -3997,7 +3997,7 @@
@smallexample
__attrib
See the following emails for a few inlined patches
to /trunk/gcc/doc/extend.texi:
[1] Docs: extend.texi: Add missing semicolon for consistency
[2] Docs: extend.texi: Remove trailing blanks from lines
[3] Docs: extend.texi: Rearrange nodes; no text was removed or added
[4] Docs: extend.texi
On 4/20/11, Jason Merrill wrote:
> On 04/20/2011 11:38 AM, Diego Novillo wrote:
>> I don't know. I thought pushdecl_with_scope would be it. Jason, is
>> there any other bookkeeping routine we would need to be calling?
>> Maybe we need to set some global that points to the current namespace
>> be
Then the combiner is doing exactly what it is supposed to given the information
it has.
"clobber x" means "there is no useful data in x". So the combiner can't
combine that with the compare, because the first insn doesn't produce a valid
CC according to how it is defined.
I would write it as
Hi Paul,
On i386 (and X86_64) RTL for insn X is generated with a "(clobber reg:CC
FLAGS_REG)" instead of indicating exactly what is written on flags regs. I
don't know if this could be different (as you suggested).
Maybe the idea is combine "operation insns" and "test insns" later, but
com
On Wed, Apr 27, 2011 at 12:45 PM, Ian Lance Taylor wrote:
> Deryck Hodge writes:
>
>> I work at Canonical on Launchpad and am trying to setup syncing
>> between our bug tracker and the GCC bug tracker. Specifically, we
>> want to enable comment syncing between linked bugs on our trackers and
>>
Ian Lance Taylor wrote:
Does any gcc maintainer object to setting this up? It sounds like a
good idea to me.
I concur.
I think the simple way for you to do this is to just create an account
on the gcc bugzilla (http://gcc.gnu.org/bugzilla/). Then I can grant
that account the necessary right
On Apr 27, 2011, at 3:15 PM, cirrus75 wrote:
>
> Hello Ian,
>
> One example is:
>
> insn X : "REG_X = "
> insn X+1 : "MEM(addr) = REG_X"
> insn X+2 : "REGY:CCmode compare(REG_X, const_int 0)"
>
> generated by C code (already posted by me some weeks ago):
> --
>
> int a, b, c, d;
>
Hello Ian,
One example is:
insn X : "REG_X = "
insn X+1 : "MEM(addr) = REG_X"
insn X+2 : "REGY:CCmode compare(REG_X, const_int 0)"
generated by C code (already posted by me some weeks ago):
--
int a, b, c, d;
int foo()
{
a += b;
if(a)
c = d;
}
Insns X+2 and X can usua
Hello, I'm studying the code of GCC to now how does it work and some
other purposes...
Can anyone tell me how does its error recovery work?
I think it is something near to Panic method, but I'm not sure and no
documents exist about it!
Thank in advance...
--
Free Software : Freedom to be Free...
On Wed, Apr 27, 2011 at 7:45 PM, Ian Lance Taylor wrote:
> Deryck Hodge writes:
>
>> I work at Canonical on Launchpad and am trying to setup syncing
>> between our bug tracker and the GCC bug tracker. Specifically, we
>> want to enable comment syncing between linked bugs on our trackers and
>> b
Deryck Hodge writes:
> I work at Canonical on Launchpad and am trying to setup syncing
> between our bug tracker and the GCC bug tracker. Specifically, we
> want to enable comment syncing between linked bugs on our trackers and
> back links from your Bugzilla to the Launchpad bug. Currently we
cirrus75 writes:
> I am trying to improve combine pass (for all backends). One approach is
> changing the order of some insns before combine pass starts. The first
> problem I have is about the REGNOTES, they need to be rebuilt after changing
> insn order. Does anyone know how to do that ?
>> Here are some areas I'll look closer to, as shown by some early profiling
>> I performed:
>> * hash tables (both htab and symtab)
>
> There is probably a lot of tuning possible around GCC hash tables.
Yes. I'd like to mention that I have been working on this myself during the
past weeks and
Hi,
I work at Canonical on Launchpad and am trying to setup syncing
between our bug tracker and the GCC bug tracker. Specifically, we
want to enable comment syncing between linked bugs on our trackers and
back links from your Bugzilla to the Launchpad bug. Currently we only
sync status and impor
Hi All,
I am trying to improve combine pass (for all backends). One approach is
changing the order of some insns before combine pass starts. The first problem
I have is about the REGNOTES, they need to be rebuilt after changing insn
order. Does anyone know how to do that ?
Does anyone k
So, I have a machine that has many styles of branches, among them, a normal
one, and a short version. The short version is cheaper (sometimes). The
regular one is 1 (predicted), 7 mis-predicted. The cost of mis-prediction can
be substantially higher depending upon what is in the cache. The s
On Wed, Apr 27, 2011 at 06:07:58AM -0700, Richard Guenther wrote:
> * Speedup_areas wiki page is very interesting, but lacks measurements to
> help me assess the weight of each area mentioned. Any comments on those?
On Wed, Apr 27, 2011 at 3:06 PM, Dimitrios Apostolou wrote:
> General comment: w
On Wednesday 27 April 2011 18:25:40 Alan Stern wrote:
> On Wed, 27 Apr 2011, Rabin Vincent wrote:
>
> > On Wed, Apr 27, 2011 at 00:21, Alan Stern wrote:
> > > On Tue, 26 Apr 2011, Rabin Vincent wrote:
> > >> In my case it's this writel() in ehci-hub.c that gets chopped into
> > >> strbs:
> > >>
>
On Wed, 27 Apr 2011, Rabin Vincent wrote:
> On Wed, Apr 27, 2011 at 00:21, Alan Stern wrote:
> > On Tue, 26 Apr 2011, Rabin Vincent wrote:
> >> In my case it's this writel() in ehci-hub.c that gets chopped into
> >> strbs:
> >>
> >> � � � /* force reset to complete */
> >> � � � ehci_writel(ehci,
On Wed, Apr 27, 2011 at 04:06:48PM +0300, Dimitrios Apostolou wrote:
> Hello list,
>
> I am Dimitris (IRC nick: jimis), and this summer I will be working
> on optimising GCC, under the umbrella of Google Summer of Code. My
> proposal involves profiling and benchmarking in order to detect
> hotspot
On Wed, Apr 27, 2011 at 00:21, Alan Stern wrote:
> On Tue, 26 Apr 2011, Rabin Vincent wrote:
>> In my case it's this writel() in ehci-hub.c that gets chopped into
>> strbs:
>>
>> /* force reset to complete */
>> ehci_writel(ehci, temp & ~(PORT_RWC_BITS | PORT_RESET),
>>
Hi, Richard
> Any other advice will be appreciated.
I think you can look into llvm-clang. It compiles faster and uses much less
memory than gcc.
I would also like to see that size of gcc binary (cc1, cc1plus, etc.) is
reduced.
Yuan Pengfei
Peking Unversity, China
On Wed, Apr 27, 2011 at 3:06 PM, Dimitrios Apostolou wrote:
> Hello list,
>
> I am Dimitris (IRC nick: jimis), and this summer I will be working on
> optimising GCC, under the umbrella of Google Summer of Code. My proposal
> involves profiling and benchmarking in order to detect hotspots in both C
Hello list,
I am Dimitris (IRC nick: jimis), and this summer I will be working on
optimising GCC, under the umbrella of Google Summer of Code. My proposal
involves profiling and benchmarking in order to detect hotspots in both
CPU and memory usage, and improving or rewriting the respective par
"Joseph S. Myers" writes:
> See PR 48580 for discussion of possible approaches for representing
> overflow detection and handling (and, in particular, making -ftrapv work
> properly and making -fwrapv and -ftrapv affect the IR generated by front
> ends instead of being global flags), both in G
See PR 48580 for discussion of possible approaches for representing
overflow detection and handling (and, in particular, making -ftrapv work
properly and making -fwrapv and -ftrapv affect the IR generated by front
ends instead of being global flags), both in GIMPLE and at the C source
level.
-
Hi,
I was wondering whether there is an easy way for a front end to detect
whether an integer overflow had occurred? Currently the GNU Modula-2
front end will detect cardinal number and integer subrange out of bound
(during assignment, INC and DEC). However it does not detect overflows
for thes
On Tue, Apr 26, 2011 at 1:44 AM, Ian Lance Taylor wrote:
> Liu writes:
>
>> I get a error:
>> /opt/cross-tools/bin/../lib/gcc/mips64el-unknown-linux-gnu/4.5.1/include/xx.h:1535:31:
>> error: invalid argument to built-in function
>
> That is an error from the MIPS backend.
>
> In this case it seem
43 matches
Mail list logo