On Sun, 2009-10-11 at 20:20 +0530, sandeep soni wrote:
> Hi All,
>
> I have been studying the gcc code lately as part of my project.I have
> got info from this mailing list about CFG and DFG information.I want
> to know how gcc uses this information to perform loop optimization?
> Does it Follow a
On 10/12/09 19:18, Michael Matz wrote:
Hi,
On Mon, 12 Oct 2009, Jeff Law wrote:
To put things in perspective, the particular person I spoke with spent
many days trying to understand why a particular function wasn't being
inlined -- presumably they'd see "grep logfile" as a
huge improvemen
Hi,
On Mon, 12 Oct 2009, Jeff Law wrote:
> To put things in perspective, the particular person I spoke with spent
> many days trying to understand why a particular function wasn't being
> inlined -- presumably they'd see "grep logfile" as a
> huge improvement over the days and days of twiddli
Hi,
On Mon, 12 Oct 2009, Jason Merrill wrote:
> On 10/12/2009 10:22 AM, Paolo Bonzini wrote:
> > Yep. Anyone deleting dead branches should add a link to the last "live"
> > version in branches.html. It seems easier to me to move them under
> > branches/dead, and possibly create branches/merged.
>
On 10/10/09 10:40, Richard Guenther wrote:
Well - that will print one diagnostic per callgraph edge. A bit too much, no?
Possibly -- it's not yet clear (to me) how to present this data to
users, but it's clearly something they're interested in.
To put things in perspective, the particula
On 10/12/2009 05:17 PM, Andrew Pinski wrote:
That seems like a huge bug in git-svn because we already use multiple
directory levels under branches. Hint ibm and redhat and debain.
Yep, that's why I said "expand". I've thought about fixing that aspect
of git-svn, but I'm not sure how it would
On Mon, Oct 12, 2009 at 2:15 PM, Jason Merrill wrote:
> On 10/12/2009 10:22 AM, Paolo Bonzini wrote:
>>
>> Yep. Anyone deleting dead branches should add a link to the last "live"
>> version in branches.html. It seems easier to me to move them under
>> branches/dead, and possibly create branches/me
On 10/12/2009 10:22 AM, Paolo Bonzini wrote:
Yep. Anyone deleting dead branches should add a link to the last "live"
version in branches.html. It seems easier to me to move them under
branches/dead, and possibly create branches/merged.
Multiple directory levels under branches/ confuse git-svn;
On Mon, Oct 12, 2009 at 11:28 PM, Ian Lance Taylor wrote:
> sandeep soni writes:
>
>> On Mon, Oct 12, 2009 at 12:13 PM, Ian Lance Taylor wrote:
>>
>>> I'm not really sure what you are asking. gcc supports OpenMP for
>>> parallelizing loops. That is mostly done in the frontends.
>>
>> I have be
sandeep soni writes:
> On Mon, Oct 12, 2009 at 12:13 PM, Ian Lance Taylor wrote:
>
>> I'm not really sure what you are asking. gcc supports OpenMP for
>> parallelizing loops. That is mostly done in the frontends.
>
> I have been told that openMP does parallelizing of loops, but these
> types o
On Mon, Oct 12, 2009 at 12:13 PM, Ian Lance Taylor wrote:
> I'm not really sure what you are asking. gcc supports OpenMP for
> parallelizing loops. That is mostly done in the frontends.
I have been told that openMP does parallelizing of loops, but these
types of optimizations are generally don
Thomas Heller writes:
> I ran into a little issue when trying to force inlining with
> __attribute__(( always_inline )). The reason why i am trying to force
> the compiler to inline my code is simple: I want to implement handwritten
> optimizations using SSE intrinsics. However it seems that gcc
Hi list,
I ran into a little issue when trying to force inlining with
__attribute__(( always_inline )). The reason why i am trying to force
the compiler to inline my code is simple: I want to implement handwritten
optimizations using SSE intrinsics. However it seems that gcc is not willing
to in
Loren James Rittle writes:
> Since around Wednesday of last week, I have been unable to access
> svn+ssh://ljrit...@gcc.gnu.org/svn/gcc through
> http://sshproxy.sourceware.org:443/
>
> I have not changed any local configuration in some time but definitely
> not since it worked the day before tha
jeffiedward writes:
> when i try to compile glibc, the following configuration error occurs:
>
> ../configure CFLAGS=" -march=i686 -O2" --host=i686-pc-linux-gnu
> --target=powerpc-linux-gnu --prefix=/home/tellabs/GNU/PPC
> --with-headers=/home/tellabs/GNU/include
> --with-binutils=/home/tellabs/G
Since around Wednesday of last week, I have been unable to access
svn+ssh://ljrit...@gcc.gnu.org/svn/gcc through
http://sshproxy.sourceware.org:443/
I have not changed any local configuration in some time but definitely
not since it worked the day before that.
I do not control the outbound gatewa
On Mon, Oct 12, 2009 at 08:09:48AM -0700, Bingfeng Mei wrote:
> Richard,
> Doesn't REGISTER_TARGET_PRAGMAS need to call c_register_pragma, etc, if we
> want to specify target-specific pragma? It becomes part of libbackend.a,
> which is linked to lto1. One solution I see is to put them into a separ
On 10/12/2009 08:09 AM, Bingfeng Mei wrote:
Richard,
Doesn't REGISTER_TARGET_PRAGMAS need to call c_register_pragma, etc, if we
want to specify target-specific pragma? It becomes part of libbackend.a,
which is linked to lto1. One solution I see is to put them into a separate
file so the linker wo
2009/10/12 Paolo Bonzini :
>
>>> That exactly is the problem. You can't have a CONST_INT inside a
>>> ZERO_EXTEND. That is not valid.
>>> You'll need a separate pattern to recognize the CONST_INT without a
>>> ZERO_EXTEND around it. Unfortunately, this will not give reload
>>> the freedom it sho
Richard,
Doesn't REGISTER_TARGET_PRAGMAS need to call c_register_pragma, etc, if we
want to specify target-specific pragma? It becomes part of libbackend.a,
which is linked to lto1. One solution I see is to put them into a separate
file so the linker won't produce undefined references when they ar
On Mon, Oct 12, 2009 at 4:31 PM, Bingfeng Mei wrote:
> Hello,
> I ran into an issue with the LTO merges when updating to current trunk.
> The problem is that my target calls a few functions/uses some data structures
> in the gcc directory: c_language, paragma_lex, c_register_pragma, etc.
>
> gcc -
Hello,
I ran into an issue with the LTO merges when updating to current trunk.
The problem is that my target calls a few functions/uses some data structures
in the gcc directory: c_language, paragma_lex, c_register_pragma, etc.
gcc -m32 -g -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-s
On 09/25/2009 09:35 PM, Joseph S. Myers wrote:
Viewing deleted files and their history (and for SVN deleted branches are
just a special case of deleted files) is something SVN is bad at since you
do need to work out the last revision the file was present first.
Yep. Anyone deleting dead branch
in libstdc++-v3:
configure:57398: error: No support for this host/target combination.
Used to work for the gcc-4.4.x series.
Any ideas?
Rainer
That exactly is the problem. You can't have a CONST_INT inside a
ZERO_EXTEND. That is not valid.
You'll need a separate pattern to recognize the CONST_INT without a
ZERO_EXTEND around it. Unfortunately, this will not give reload
the freedom it should have.
You mean I should remove the con
2009/10/12 Joern Rennecke :
> Quoting daniel tian :
>
>> hi, everyone:
>> I have ported the gcc to new RISC chip. But when I build the
>> newlib with it, the gcc crashed in simplify-rtx.c.
>> error message is like this:
>>
>> ../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c: In
>
Quoting daniel tian :
hi, everyone:
I have ported the gcc to new RISC chip. But when I build the
newlib with it, the gcc crashed in simplify-rtx.c.
error message is like this:
../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c: In
function _tzset_r?
../../../../../newli
2009/10/12 Jon Beniston :
>> PS: Does gcc have a function which could dump the specified rtx?
>> I wanna dump the rtx when the crash happening.
>
> debug_rtx(x);
>
> You can also call this from within GDB, by typing:
>
> call debug_rtx(x)
>
> Cheers,
> Jon
>
Thanks.
I dump the context. Here it is:
Hi,
I'm new to the GNU tool building environment.
I'm trying to build cross GCC for powerpc-linux platform.
I could compile binutils and first-stage gcc.
These are my configuration options:
binutils:
../configure --prefix=/home/tellabs/GNU/PPC --target=powerpc-linux-gnu
make all
make i
> PS: Does gcc have a function which could dump the specified rtx?
> I wanna dump the rtx when the crash happening.
debug_rtx(x);
You can also call this from within GDB, by typing:
call debug_rtx(x)
Cheers,
Jon
hi, everyone:
I have ported the gcc to new RISC chip. But when I build the
newlib with it, the gcc crashed in simplify-rtx.c.
error message is like this:
../../../../../newlib-1.16.0/newlib/libc/time/tzset_r.c: In
function _tzset_r?
../../../../../newlib-1.16.0/newlib/libc/time
On Mon, Oct 12, 2009 at 10:53 AM, Rainer Emrich
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Richard Guenther schrieb:
>> On Sun, Oct 11, 2009 at 6:21 PM, Richard Guenther
>> wrote:
>>> On Sun, Oct 11, 2009 at 6:04 PM, Rainer Emrich
>>> wrote:
-BEGIN PGP SIGNED MESSAGE--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Richard Guenther schrieb:
> On Sun, Oct 11, 2009 at 6:21 PM, Richard Guenther
> wrote:
>> On Sun, Oct 11, 2009 at 6:04 PM, Rainer Emrich
>> wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> libtool: link: gcc -shared .libs/lto-plu
33 matches
Mail list logo
