Hi :
I'm wondering whether cfg is maintained properly during delay slot
scheduling,
Because when compiling libgcc/_divsc3.o, rtl dump in
libgcc2.c.198r.mach has following lines:
no bb for insn with uid = 293.
deleting insn with uid = 690.
deleting insn with uid = 904.
..
(note 298 905 303
On Fri, Apr 2, 2010 at 11:28 AM, Amker.Cheng wrote:
> Hi :
> I'm wondering whether cfg is maintained properly during delay slot
> scheduling,
The CFG is not maintained during delay slot scheduling. This is, in
fact, a very old and well-known problem. Look for any e-mail on this
list that mentio
> The CFG is not maintained during delay slot scheduling. This is, in
> fact, a very old and well-known problem. Look for any e-mail on this
> list that mentions reorg.c :-)
>
Thanks, further more , It seems cfg are not maintained after delay
slot scheduling.
also find that problem just before fina
On Fri, Apr 2, 2010 at 12:41 PM, Amker.Cheng wrote:
>> The CFG is not maintained during delay slot scheduling. This is, in
>> fact, a very old and well-known problem. Look for any e-mail on this
>> list that mentions reorg.c :-)
>>
> Thanks, further more , It seems cfg are not maintained after del
I have noticed a tendency for timeouts to occur
in the 20_util/shared_ptr/thread/default_weaktoshared.cc...
Executing on host:
/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/./gcc/g++
-shared-libgcc -B/sw/src/fink.build/gcc45-4.4.999-20100401/darwin_objdir/./gcc
-nostdinc++
-L/sw/s
On 04/02/2010 02:09 PM, Jack Howarth wrote:
> Is there a PR related to this and if not shouldn't one be opened?
>
I never times out for me on x86 and x86_64-linux. Thus, if you want to
open one, I would suggest a target PR. Jon may know better...
Paolo.
On Fri, Apr 02, 2010 at 02:15:05PM +0200, Paolo Carlini wrote:
> On 04/02/2010 02:09 PM, Jack Howarth wrote:
> > Is there a PR related to this and if not shouldn't one be opened?
> >
> I never times out for me on x86 and x86_64-linux. Thus, if you want to
> open one, I would suggest a target PR.
On 04/02/10 05:26, Steven Bosscher wrote:
Yes. The CFG is constructed on GIMPLE and then maintained all the way
through to reorg.c (or actually pass_free_cfg). Once destroyed, we
cannot resurrect the CFG.
In a perfect world, reorg.c would get a rewrite and we'd maintain the
CFG all the way thro
On Fri, Apr 2, 2010 at 4:26 PM, Jeff Law wrote:
> On 04/02/10 05:26, Steven Bosscher wrote:
>>
>> Yes. The CFG is constructed on GIMPLE and then maintained all the way
>> through to reorg.c (or actually pass_free_cfg). Once destroyed, we
>> cannot resurrect the CFG.
>>
>> In a perfect world, reorg
On 2 April 2010 14:12, Jack Howarth wrote:
>
> Paolo,
> I don't believe this occurs with the x86_64-apple-darwin10
> target but only with i686-apple-darwin10 so it may well be
> a bug in the 32-bit linker on darwin. I'll try benchmarking the
> actual linkage command at both 32-bit and 64-bit to s
Hi,
I ran into a lot of GCC test failures on a
Coldfire target board which did not use the default
multilib. When I investigated, it turned out
that this line in the site.exp rule in gcc/Makefile.in
was causing it to link the default 68020
multilib instead of the right Coldfire one.
echo "set
On Mon, 29 Mar 2010 12:55:47 -0400 Jack Howarth
wrote:
>I've not seen any discussion of testing gcc trunk
> against the newer gmp 5.0 or 5.0.1 releases. Has anyone
> done significant testing with the newer gmp releases
> ... ?
I use gcc 4.4.4 and 4.5.0 with gmp 5.0.1. I compile and use Postg
On Thu, Apr 1, 2010 at 11:56 PM, Michael Han wrote:
> Hello,
>
> May I know where or whom should I contact to obtain the copyright
> assignment form? I want to contribute some code to gcc so I think
> having these forms in place earlier would be a good idea.
Assignment request form sent privately
Hello Everyone,
I am trying to build an OpenRISC port of GCC. I am not getting much
response from the OR32 people, and this error sounds a bit generic from google
searches so I thought if someone would know how to solve it.
I build binutils, gcc and newlib as they mentioned in the or32 we
Hi,
r157834 of the trunk made compilation time almost 8(eight!) times
longer. The time went from 38 to 291 seconds.
$ svnversion ~/src/gcc
157833
$ make -C ~/src/gcc install
...
$ /usr/bin/time g++ -std=c++0x -O2 -g -Wall -Werror -Wno-unused \
-Wno-parentheses -I../ check.cpp -o check -MMD -lrt
3
On Fri, Apr 2, 2010 at 8:47 PM, Roman Kononov wrote:
> Hi,
>
> r157834 of the trunk made compilation time almost 8(eight!) times
> longer. The time went from 38 to 291 seconds.
>
> $ svnversion ~/src/gcc
> 157833
> $ make -C ~/src/gcc install
> ...
> $ /usr/bin/time g++ -std=c++0x -O2 -g -Wall -We
On 2010-04-02, 20:50 CDT, Richard Guenther said:
>The patch is about debuginfo. Can you file a bugzilla and attach
>preprocessed source for the testcase?
$g++ -E -std=c++0x -I../ check.cpp | sed -r '/^( *|\#.*)$/d' | wc -l
24526
The preprocessed source has 24526 non-blank lines. Should I attach
On Fri, Apr 2, 2010 at 9:11 PM, Roman Kononov wrote:
> On 2010-04-02, 20:50 CDT, Richard Guenther said:
>>The patch is about debuginfo. Can you file a bugzilla and attach
>>preprocessed source for the testcase?
>
> $g++ -E -std=c++0x -I../ check.cpp | sed -r '/^( *|\#.*)$/d' | wc -l
> 24526
>
> T
On Fri, Apr 02, 2010 at 06:10:29PM +0100, Jonathan Wakely wrote:
> On 2 April 2010 14:12, Jack Howarth wrote:
> >
> > Paolo,
> > I don't believe this occurs with the x86_64-apple-darwin10
> > target but only with i686-apple-darwin10 so it may well be
> > a bug in the 32-bit linker on darwin. I'll
On 03/04/10 03:28, Roman Kononov wrote:
On Mon, 29 Mar 2010 12:55:47 -0400 Jack Howarth
wrote:
I've not seen any discussion of testing gcc trunk
against the newer gmp 5.0 or 5.0.1 releases. Has anyone
done significant testing with the newer gmp releases
... ?
I use gcc 4.4.4 an
Hi Mike,
I'm sorry to spend a week to response your replay, and thank you
for explanation of -save-temps=obj specifications.
> I tend to agree with Richard, that if there are multiple source inputs, it
> should be an error to use -save-temps=obj without the -c/-S option.
I reached a true underst
Sorry, I miss. follow it:
2010/4/3 Tadashi Koike :
> Hi Mike,
>
> I'm sorry to spend a week to response your replay, and thank you
> for explanation of -save-temps=obj specifications.
>
>> I tend to agree with Richard, that if there are multiple source inputs, it
>> should be an error to use -save
22 matches
Mail list logo
