Hi,
On Wed, 14 Oct 2009, Ben Elliston wrote:
> I deleted a personal branch from 5 years ago and have added the revision
> number of the delete commit to the branch description in svn.html.
>
> Would these two conventions suffice?
Well, I'm always of the opinion that it's better to have some te
On Oct 12, 2009, Jason Merrill wrote:
> 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
>
Oh, hello Yuri, nice to meet you here :)
Alexey
On Tue, Oct 13, 2009 at 7:51 PM, Yuri Kashnikoff
wrote:
>> Therefore, the most effective way to address the issue of running redundant
>> optimization passes in the context is probably to put it in the wider
>> context
>> of the work to allow exter
On 10/13/2009 08:50 PM, Ben Elliston wrote:
I found that svn log works well if you do this:
svn log svn+ssh://b...@gcc.gnu.org/svn/gcc | less
Which in recent versions of svn can also be written
svn log ^/ |less
if you're in an SVN working directory.
Jason
Joern Rennecke wrote:
> But at any rate, the subject does not agree with
> the content of the original post. When we talk
> about a 'regression' in a particular gcc version,
> we generally mean that this version is in some
> way worse than a previous version of gcc.
Didn't the original poster ind
Joern Rennecke writes:
> Quoting Ian Lance Taylor :
>
>> francesco biscani writes:
>>
>>> I'm experiencing a strange behaviour with GCC 4.4.1. Basically I have
>>> some C++ mathematical code which gets a ~x2 performance drop if I
>>> *remove* the following debug line from the code:
>>
>>
>> This
On Thu, Oct 08, 2009 at 08:52:03PM +0200, Jakub Jelinek wrote:
> The first release candidate for GCC 4.4.2 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.4.2-RC-20091008
>
> and shortly its mirrors. It has been generated from SVN revision 152546.
>
> I have so far bootstrapped an
Quoting Daniel Berlin :
Branches always start with a copy of a directory somewhere else, at
least in the gcc repo.
Further, at least in the gcc repo, all branches start with a copy of a
directory from branches or from trunk.
So, it's fairly easy to detect branches.
I disagree. In svn, you can
Quoting Ian Lance Taylor :
francesco biscani writes:
I'm experiencing a strange behaviour with GCC 4.4.1. Basically I have
some C++ mathematical code which gets a ~x2 performance drop if I
*remove* the following debug line from the code:
This message is not appropriate for the mailing list
On Mon, Oct 12, 2009 at 5:20 PM, Jason Merrill wrote:
> 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 a
On Tue, 2009-10-13 at 03:05 +0200, Michael Matz wrote:
> I don't think we should necessarily limit ourself by bugs in foreign tools
> if it reduces useful information. What about a new top-level directory
> dead-branches/, not under branches/ but parallel to it? Should be easy to
> exempt fro
Snapshot gcc-4.4-20091013 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20091013/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
francesco biscani writes:
> I'm experiencing a strange behaviour with GCC 4.4.1. Basically I have
> some C++ mathematical code which gets a ~x2 performance drop if I
> *remove* the following debug line from the code:
This message is not appropriate for the mailing list g...@gcc.gnu.org.
It is a
Hi list,
I'm experiencing a strange behaviour with GCC 4.4.1. Basically I have
some C++ mathematical code which gets a ~x2 performance drop if I
*remove* the following debug line from the code:
---
std::cout << "Block size: " << block_size << '\n';
---
Where block_size
On 10/13/2009 12:09 PM, Dave Korn wrote:
Alas that doesn't prevent the conflicts, it just makes them "was removed on
trunk" rather than "was changed on trunk"! Well, that's what happened to me
anyway. It's a shame that svn doesn't have separate --accept types for files
and for properties, th
Richard Henderson wrote:
> Managing branches with svnmerge is nice and friendly. Certainly much
> easier than doing it by hand. However, when it comes time to integrate
> that branch into mainline, one must use more caution.
>
> If you use svnmerge on your branch, and then integrate the branch t
On 10/13/09 11:34, Richard Henderson wrote:
Managing branches with svnmerge is nice and friendly. Certainly much
easier than doing it by hand. However, when it comes time to
integrate that branch into mainline, one must use more caution.
If you use svnmerge on your branch, and then integrate
Jeff Law wrote:
On 10/10/09 09:17, Daniel Jacobowitz wrote:
On Sat, Oct 10, 2009 at 02:31:25PM +0200, Jan Hubicka wrote:
My solution would be probably to pass -fdump-ipa-inline parameter to lto
compilation and read the log. It lists the inlining decisions and if
something is not inlined,
Paul Brook writes:
>> Nothing you've said changes the fact that there are a class of users
>> for whom that information is vital and we ought to spend some time
>> thinking about how to provide the information in a form they can
>> digest. GCC dumps as they exist today are largely useless for a
Managing branches with svnmerge is nice and friendly. Certainly much
easier than doing it by hand. However, when it comes time to integrate
that branch into mainline, one must use more caution.
If you use svnmerge on your branch, and then integrate the branch to
mainline with "svn merge" (as
> I added myself (Edward Smith-Rowland) to MAINTAINERS (Write After
> Approval).
Thanks!
Look forward to seeing more of your work, and hope that working on gcc
branches directly is helpful to you.
best,
benjamin
On Tue, Oct 13, 2009 at 5:18 PM, Bingfeng Mei wrote:
>
>
>> -Original Message-
>> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> Sent: 13 October 2009 16:15
>> To: Bingfeng Mei
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: LTO question
>>
>> On Tue, Oct 13, 2009 at 2:47 PM, Bingfen
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 13 October 2009 16:15
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: LTO question
>
> On Tue, Oct 13, 2009 at 2:47 PM, Bingfeng Mei
> wrote:
> > Hello,
> > I just had the first taste wi
On Tue, Oct 13, 2009 at 2:47 PM, Bingfeng Mei wrote:
> Hello,
> I just had the first taste with the latest LTO merge on our port.
> Compiler is configured with LTO enabled and built correctly.
> I tried the following example:
>
> a.c
> extern void foo(int);
> int main()
> { foo(20);
> return 1;
On 10/13/09 03:41, Paul Brook wrote:
Nothing you've said changes the fact that there are a class of users
for whom that information is vital and we ought to spend some time
thinking about how to provide the information in a form they can
digest. GCC dumps as they exist today are largely useless
On Tue, Oct 13, 2009 at 09:46, Bingfeng Mei wrote:
> Thanks. It works. I thought -fwhole-program was used with --combine and they
> are replaced
> by -flto. Now it seems that -flto is equivalent of --combine, and
> -fwhole-program is still
> important.
That's approximately correct, yes. --com
On 10/12/2009 09:05 PM, Michael Matz wrote:
I don't think we should necessarily limit ourself by bugs in foreign tools
if it reduces useful information. What about a new top-level directory
dead-branches/, not under branches/ but parallel to it? Should be easy to
exempt from git-svn handling, s
Hi,
ACATS results for (4.5.0 20091012 r152668) for
MIPS, SPARC, PowerPC, x86 and m68k/Coldfire. This is
the first time I have results for m68k/Coldfire. :)
+ ARM - does not build, regression, PR40775
+ General Failures
c380004 fails on all RTEMS targets. It requires
a very large stack to pa
Thanks. It works. I thought -fwhole-program was used with --combine and they
are replaced
by -flto. Now it seems that -flto is equivalent of --combine, and
-fwhole-program is still
important.
Bingfeng
> -Original Message-
> From: Diego Novillo [mailto:dnovi...@google.com]
> Sent: 13
On Tue, Oct 13, 2009 at 08:47, Bingfeng Mei wrote:
> a.c
> extern void foo(int);
> int main()
> { foo(20);
> return 1;
> }
>
> b.c
> #include
> void foo(int c)
> {
> printf("Hello world: %d\n", c);
> }
>
> compiled with:
> firepath-elf-gcc -flto a.c b.c -save-temps -O2
>
> I expected that foo
On Tue, Oct 13, 2009 at 10:41:39AM +0100, Paul Brook wrote:
> My guess is anyone inspecting the code and optimizer decisions at this level
> is also going to want to strongarm the result they want when the compiler
> makes the "wrong" decision. i.e. detailed unroller diagnostics are only of
> li
> Therefore, the most effective way to address the issue of running redundant
> optimization passes in the context is probably to put it in the wider
> context
> of the work to allow external plugins to influence the pass sequence that is
> being applied, and to control this with machine learning.
Hello,
I just had the first taste with the latest LTO merge on our port.
Compiler is configured with LTO enabled and built correctly.
I tried the following example:
a.c
extern void foo(int);
int main()
{ foo(20);
return 1;
}
b.c
#include
void foo(int c)
{
printf("Hello world: %d\n",
Ed Smith-Rowland wrote:
> I added myself (Edward Smith-Rowland) to MAINTAINERS (Write After
> Approval).
>
> I work on libstdc++.
>
> Thanks all, especially my mentors Paolo Carlini and Benjamin Kosnik ;-),
The first one thanks and recommends:
1- Not sending patches to gcc@
2- Not sending ChangeLo
I added myself (Edward Smith-Rowland) to MAINTAINERS (Write After Approval).
I work on libstdc++.
Thanks all, especially my mentors Paolo Carlini and Benjamin Kosnik ;-),
Ed Smith-Rowland
Index: libstdc++-v3/include/precompiled/stdc++.h
=
Paul Brook writes:
>> Here is a problem that '#' is a symbol used in my chip assembler as
>> prefix before immediate. Like: MOV R0 #0x123.
>> ...
>> Is there any solution to solve this?
>
> Make your assembler accept # as as a comment stat only if it appears at the
> start of a line. There are
> Here is a problem that '#' is a symbol used in my chip assembler as
> prefix before immediate. Like: MOV R0 #0x123.
> ...
> Is there any solution to solve this?
Make your assembler accept # as as a comment stat only if it appears at the
start of a line. There are several other targets (e.g. A
Hi everyone:
I have a problem with the C preprocessor. I write a assemble code
"setjmp.S". When I built it with gcc which I have ported with the
following command:
/usr/local/cross/rice-elf/libexec/gcc/rice-elf/4.3.0/cc1 -E
-lang-asm -quiet -v -DHAVE_RENAME -DMISSING_SYSCALL_NAMES -isystem
> Nothing you've said changes the fact that there are a class of users
> for whom that information is vital and we ought to spend some time
> thinking about how to provide the information in a form they can
> digest. GCC dumps as they exist today are largely useless for a non-GCC
> developer to u
39 matches
Mail list logo
