Du Toan G8, Phan mem du toan cong trinh uu viet nhat hien nay!

2011-07-01 Thread Du Toan G8
Công Ty Cổ phần Đầu Tư Tư Vấn Xây Dựng AN VIỆT xin trân trọng giới thiệu phần mềm Dự toán - Dự thầu G8 ,hiện là một trong những sản phẩm chiến lược của chúng tôi. Phần mềm Dự toán – Dự thầu G8 hiện nay đã được tin dùng

[rs6000] -mno-sched-prolog vs .debug_frame

2011-07-01 Thread Richard Henderson
The implementation of TARGET_SCHED_PROLOG is incompatible with some coming changes to how dwarf2 cfi is to be generated. Some suggested solutions are: (1) Remove the option. Is it really that interesting beyond -mno-sched-insns2? (2) Emit blockage insns at the end of the prologue an

gcc-4.6-20110701 is now available

2011-07-01 Thread gccadmin
Snapshot gcc-4.6-20110701 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110701/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: viewcvs: Python error

2011-07-01 Thread Ian Lance Taylor
> Ian Lance Taylor schrieb: > >> Thanks for identifying the patch. I applied the reverse patch manually >> to gcc.gnu.org, and the problem appears to be fixed, at least for now. >> >> Ian > > Hi, thanks for the fix, but it appears the revert changed bit too > much. This issue has returned: > > htt

Re: Validity of __asm__ transformation with "m" reference

2011-07-01 Thread Martin Thuresson
Jacub, On Fri, Jul 1, 2011 at 12:04 PM, Jakub Jelinek wrote: > On Fri, Jul 01, 2011 at 11:45:16AM -0700, Martin Thuresson wrote: >> In recent versions of GCC I have seen a transformation of inline >> assembly that I'd like to confirm is valid. >> >> The code in question can be found in mplayer/mp

Re: Validity of __asm__ transformation with "m" reference

2011-07-01 Thread Jakub Jelinek
On Fri, Jul 01, 2011 at 11:45:16AM -0700, Martin Thuresson wrote: > In recent versions of GCC I have seen a transformation of inline > assembly that I'd like to confirm is valid. > > The code in question can be found in mplayer/mp3lib/dct64_sse.c > > "movaps%0, %%xmm0\n\t" >

Re: viewcvs: Python error

2011-07-01 Thread Georg-Johann Lay
Ian Lance Taylor schrieb: Vincent Legoll writes: This may be the changeset that broke pygments running on older pythons (< 2.4): https://bitbucket.org/birkenfeld/pygments-main/changeset/8d3fbbf1ffdb Thanks for identifying the patch. I applied the reverse patch manually to gcc.gnu.org, and t

Validity of __asm__ transformation with "m" reference

2011-07-01 Thread Martin Thuresson
In recent versions of GCC I have seen a transformation of inline assembly that I'd like to confirm is valid. The code in question can be found in mplayer/mp3lib/dct64_sse.c "movaps%0, %%xmm0\n\t" "shufps$27, %%xmm0, %%xmm0\n\t" "movaps%1, %%xmm5\n\t"

Re: RFC: [GUPC] UPC-related changes

2011-07-01 Thread Gary Funck
This email is a follow-up to an email with a similar title (posted a year ago). During that time period, we have worked on making the changes suggested by Joseph Myers, Tom Tromey, and other reviewers. We have also implemented various bug fixes and improvements. Our goal with this RFC is to acqu

Re: cgraph callees availability

2011-07-01 Thread Paulo J. Matos
On 01/07/11 10:46, Richard Guenther wrote: You could add this logic to the tree-tailcall.c pass. I suppose what you really want is no dominating call rather than only a single call in total. Yes, that's true. I am currently porting the backend to 4.6.1 so I might do the changes in tree-tail

Re: cgraph callees availability

2011-07-01 Thread Richard Guenther
On Fri, Jul 1, 2011 at 11:41 AM, Paulo J. Matos wrote: > On 01/07/11 10:31, Richard Guenther wrote: >> >> It is being done because the edges are not kept up-to-date.  There is >> no other way to find callees but to walk all statements.  I also do not >> see a good reason why you would want to use

Re: cgraph callees availability

2011-07-01 Thread Paulo J. Matos
On 01/07/11 10:31, Richard Guenther wrote: It is being done because the edges are not kept up-to-date. There is no other way to find callees but to walk all statements. I also do not see a good reason why you would want to use the number of callees of a function to decide whether to emit sibca

Re: cgraph callees availability

2011-07-01 Thread Richard Guenther
On Fri, Jul 1, 2011 at 11:10 AM, Paulo J. Matos wrote: > > > On 01/07/11 09:38, Paulo J. Matos wrote: > >> In GCC4.4 function test presents 2 callees foo() and bar() and the >> sibcall is not done. In GCC4.5 the sibcall is done (but shouldn't) >> because callees in cgraph is 0x0. I wonder if this

Re: cgraph callees availability

2011-07-01 Thread Paulo J. Matos
On 01/07/11 09:38, Paulo J. Matos wrote: In GCC4.4 function test presents 2 callees foo() and bar() and the sibcall is not done. In GCC4.5 the sibcall is done (but shouldn't) because callees in cgraph is 0x0. I wonder if this information is not available anymore at this point and if there's so

cgraph callees availability

2011-07-01 Thread Paulo J. Matos
Hi, In TARGET_FUNCTION_OK_FOR_SIBCALL I use the number of callees of the current_function_decl to decide if a sibcall should be done. I have: int aaa[9]; __attribute__ ((noinline)) int *foo(void) { return aaa; } __attribute__ ((noinline)) void bar(int *a) { a[0] = 0x1234; } void test(void)