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
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
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
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 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 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 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
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
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
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
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
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 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
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 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 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/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.
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 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
> 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 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
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
22 matches
Mail list logo
