date:20110701

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)
{
int *x;
x = foo();
x[8] = 1;
bar(x);
}


I then use this code in TARGET_FUNCTION_OK_FOR_SIBCALL:

node = cgraph_get_node(current_function_decl);
if(node == NULL)
return false;

for(edge = node->callees; edge; edge = edge->next_callee)
if(++ncallees > 1)
return false;

return true;

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 something I can do about it.


Cheers,
--
Paulo Matos

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 something I can do about it.



After some digging around I noticed GCC4.5 introduces:
NEXT_PASS (pass_remove_cgraph_callee_edges);

I am wondering why this is being done. Are we just freeing resources or 
is there any other reason? Is there any other way to find callees 
without this information?


Cheers,

--
PMatos

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 information is not
>> available anymore at this point and if there's something I can do about
>> it.
>>
>
> After some digging around I noticed GCC4.5 introduces:
> NEXT_PASS (pass_remove_cgraph_callee_edges);
>
> I am wondering why this is being done. Are we just freeing resources or is
> there any other reason? Is there any other way to find callees without this
> information?

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 sibcalls from it.

Richard.

> Cheers,
>
> --
> PMatos
>
>

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 sibcalls from it.



Thanks for the input Richard. Makes sense. One way which seems to work 
is to obviously add a pass to rebuild the cgraph edges before 
pass_expand and remove them afterwards.


The reason why I need them is that I need know if a given register is 
live. I can check this when I expand_epilogue but not during expand 
(because RA has not been done). This special register is used for the 
return address of a function. So, if it is live it tells me that there 
was another function call besides the sibcall. If there was, it means I 
have to emit some extra instructions to do the sibcall. However, if I 
have to emit extra instructions then I don't actually want to do the 
sibcall cause I will be adding to the resulting size of the function 
which goes against our backend port policy.


By checking if there is more than 1 callee (an extra function called 
besides the sibcall) then I will know if I will need extra instructions 
or not and if I do, I say the function is _not_ ok for sibcall.


I guess if I don't want to add the extra passes before and after pass 
expand then I have to walk the statements. Sounds like it's the cleaner 
solution if I don't want to mess with the core.


Cheers,
--
PMatos

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 the number of callees
>> of a function to decide whether to emit sibcalls from it.
>>
>
> Thanks for the input Richard. Makes sense. One way which seems to work is to
> obviously add a pass to rebuild the cgraph edges before pass_expand and
> remove them afterwards.
>
> The reason why I need them is that I need know if a given register is live.
> I can check this when I expand_epilogue but not during expand (because RA
> has not been done). This special register is used for the return address of
> a function. So, if it is live it tells me that there was another function
> call besides the sibcall. If there was, it means I have to emit some extra
> instructions to do the sibcall. However, if I have to emit extra
> instructions then I don't actually want to do the sibcall cause I will be
> adding to the resulting size of the function which goes against our backend
> port policy.
>
> By checking if there is more than 1 callee (an extra function called besides
> the sibcall) then I will know if I will need extra instructions or not and
> if I do, I say the function is _not_ ok for sibcall.
>
> I guess if I don't want to add the extra passes before and after pass expand
> then I have to walk the statements. Sounds like it's the cleaner solution if
> I don't want to mess with the core.

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.

Richard.

> Cheers,
> --
> PMatos
>
>

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-tailcall on that version and leave the extra 
passes around expand in GCC 4.5.3 for now since our 4.5 is really just a 
bridge for our users to upgrade from our older 4.2/4.3 ports.

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 acquaint the reviewers with UPC and
the impact of UPC changes on the GCC front-end, and to gain consensus
that the changes are acceptable for incorporation into the GCC trunk.

Once we make further suggested changes, and have a consensus on this
batch of changes, I will send out RFC's for the "middle end"
(the lowering pass), "debugging" (UPC-specific DWARF extensions),
"runtime" (libupc) and "testing" RFC's.  Those additional RFC's
are likely to be more modular and will have less impact on
the GCC infrastructure.

The email describing the UPC-related front-end and
infrastructure changes was posted to the gcc-patches mailing list:
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00081.html

Thanks,
- Gary

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"
  "movaps%%xmm5, %%xmm6\n\t"
  :
  :"m"(*costab), "m"(*)

where  is
 static const int [4] __attribute__((aligned(16))) = { 1 << 31, 1
<< 31, 1 << 31, 1 << 31 };

GCC turns this into:
 "movaps%0, %%xmm0
  shufps$27, %%xmm0, %%xmm0
  movaps%1, %%xmm5
  movaps%%xmm5, %%xmm6
  " :  : "m" costab_mmx[24], *"m" -2147483648*);

The new constant might end up in an unaligned address causing the
program to segfault on Intel platforms.

Marking  volatile or changing the code to the following avoids the
transformation:

 __asm__(
"movaps%a0, %%xmm0\n\t"
"shufps$27, %%xmm0, %%xmm0\n\t"
"movaps%a1, %%xmm5\n\t"
"movaps%%xmm5, %%xmm6\n\t"
:
:"p"(costab), "p"()
   );

Thanks!
Martin

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 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:


http://gcc.gnu.org/ml/gcc/2011-04/msg00336.html

Johann

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"
>   "shufps$27, %%xmm0, %%xmm0\n\t"
>   "movaps%1, %%xmm5\n\t"
>   "movaps%%xmm5, %%xmm6\n\t"
>   :
>   :"m"(*costab), "m"(*)
> 
> where  is
>  static const int [4] __attribute__((aligned(16))) = { 1 << 31, 1
> << 31, 1 << 31, 1 << 31 };
> 
> GCC turns this into:
>  "movaps%0, %%xmm0
>   shufps$27, %%xmm0, %%xmm0
>   movaps%1, %%xmm5
>   movaps%%xmm5, %%xmm6
>   " :  : "m" costab_mmx[24], *"m" -2147483648*);
> 
> The new constant might end up in an unaligned address causing the
> program to segfault on Intel platforms.

But you said the operand is an int sized memory, while you expect
4 times as big data with different alignment.
So you want "m"(*(__m128d *))  (or "m"(*(__m128i *)) ).

Your "fixed" version with "p" is not correct either, because
you don't say to gcc that it reads the value from that memory address, e.g.
if there is
int foo (void)
{
  int p, q;
  p = 5;
  asm ("movl %a1, %0" : "=r" (q) : "p" (&p));
  return q;
}
gcc might very well eliminate the p = 5; store.

Jakub

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/mp3lib/dct64_sse.c
>>
>>           "movaps    %0, %%xmm0\n\t"
>>           "shufps    $27, %%xmm0, %%xmm0\n\t"
>>           "movaps    %1, %%xmm5\n\t"
>>           "movaps    %%xmm5, %%xmm6\n\t"
>>           :
>>           :"m"(*costab), "m"(*)
>>
>> where  is
>>  static const int [4] __attribute__((aligned(16))) = { 1 << 31, 1
>> << 31, 1 << 31, 1 << 31 };
>>
>> GCC turns this into:
>>      "movaps    %0, %%xmm0
>>       shufps    $27, %%xmm0, %%xmm0
>>       movaps    %1, %%xmm5
>>       movaps    %%xmm5, %%xmm6
>>       " :  : "m" costab_mmx[24], *"m" -2147483648*);
>>
>> The new constant might end up in an unaligned address causing the
>> program to segfault on Intel platforms.
>
> But you said the operand is an int sized memory, while you expect
> 4 times as big data with different alignment.
> So you want "m"(*(__m128d *))  (or "m"(*(__m128i *)) ).

Ah, thanks. Glad to hear it was a source bug and not a compiler bug. I just
verified that the solution you proposed worked in my example.

>
> Your "fixed" version with "p" is not correct either, because
> you don't say to gcc that it reads the value from that memory address, e.g.
> if there is
> int foo (void)
> {
>  int p, q;
>  p = 5;
>  asm ("movl %a1, %0" : "=r" (q) : "p" (&p));
>  return q;
> }
> gcc might very well eliminate the p = 5; store.

OK, thanks for the example.

Thanks,
Martin

>
>        Jakub
>

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:
>
> http://gcc.gnu.org/ml/gcc/2011-04/msg00336.html

Thanks.  Fixed again.

(That happened when I updated the viewvc package, it wasn't due to the
change I made.)

Ian

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/gcc-4_6-branch 
revision 175771

You'll find:

 gcc-4.6-20110701.tar.bz2 Complete GCC

  MD5=6cdff36e33b3f8684830aa1f30130e51
  SHA1=6bb0ff2e1c4ec6a3d3d0380ebb1cecbbe70cbb63

Diffs from 4.6-20110624 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[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
 and the beginning of the epilogue.  That'll prevent
 the majority of the changes that scheduling could
 introduce.

 (3) Emit the prologue and epilogue somewhere after
 scheduling and before final.  E.g. md_reorg.

I'd be delighted if someone could actually implement one
of these changes at some point in the next week, but 
failing that please weigh in on the preferred solution.


r~

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 
á» hÃ ng trÄm CÃ´ng ty, CÃ¡c sá», ban ngÃ nh, cÃ¡ nhÃ¢n vá»i sá» lÆ°á»£ng 
ngÆ°á»i dÃ¹ng lÃªn tá»i hÃ ng ngÃ n ngÆ°á»i, KhÃ´ng dá»«ng láº¡i hay tá»± 
thá»a mÃ£n lÃ  tÃ´n chá» hÃ nh Äá»ng cá»§a chÃºng tÃ´i. ChÃnh nhá»¯ng chia 
sáº», ÄÃ³ng gÃ³p vÃ´ cÃ¹ng quÃ½ bÃ¡u cá»§a quÃ½ vá» lÃ  Äá»ng lá»±c Äá» 
chÃºng tÃ´i lao Äá»ng sÃ¡ng táº¡o khÃ´ng ngá»«ng nghá» sao cho pháº§n má»m 
Dá»± toÃ¡n â Dá»± tháº§u G8 trá» nÃªn thÃ¢n thiá»n nháº¥t, chÃnh xÃ¡c, 
máº¡nh máº½ nháº¥t xá»©ng ÄÃ¡ng ká»³ vá»ng cá»§a quÃ½ vá», quÃ½ khÃ¡ch hÃ ng 
ÄÃ£ dÃ nh cho chÃºng tÃ´i thá»i gian qua.
Vá»i cÃ¡c tÃ¬nh nÄng ná»i báºt nhÆ°:
Láºp dá»± toÃ¡n, thanh quyáº¿t toÃ¡n, Äáº¥u tháº§u cÃ¡c cÃ´ng trÃ¬nh XÃ¢y 
dá»±ng, Giao thÃ´ng, Thuá»· lá»£i, Thá»§y Äiá»n, Viá»n thÃ´ng, Tráº¡m biáº¿n 
Ã¡p, ÄÆ°á»ng dÃ¢y táº£i Äiá»n, ChuyÃªn ngÃ nh Äiá»nâ¦. 
â¢  Cáºp nháºt ÄÆ¡n giÃ¡ nÄm 2008/2009, sá» dá»¥ng Äá»nh má»©c 
1776/1777/1778/1779 vÃ  táº¥t cáº£ cÃ¡c Äá»nh má»©c ban hÃ nh trÆ°á»c ÄÃ³. 
â¢ Cáºp nháºt Äáº§y Äá»§ quyáº¿t Äá»nh 957/QÄ-BXD ngÃ y 29/09/2009 
cá»§a Bá» XÃ¢y Dá»±ng vá» Äá»nh má»©c chi phiÌ quáº£n lÃ½ dá»± Ã¡n vÃ  tÆ° 
váº¥n Äáº§u tÆ° xÃ¢y dá»±ng cÃ´ng trÃ¬nh hay Nghá» Äá»nh 99/2007/NÄ-CP 
vá» quáº£n lÃ½ chi phÃ Äáº§u  tÆ° xÃ¢y dá»±ng cÃ´ng trÃ¬nh, theo ThÃ´ng tÆ° 
Sá» 05/2007/TT-BXD, thÃ´ng tÆ° 18/2008/TT-BXD vÃ  thÃ´ng tÆ° 04/2010/TT-BXD, 
tÃnh ÄÆ¡n giÃ¡ Ca mÃ¡y theo ThÃ´ng tÆ° 06/2010 Ngay 26-05-2010.
â¢ Giao diá»n thÃ¢n thiá»n giá»ng pháº§n má»m Microsoft Excel. 
â¢ CÃ³ nhiá»u cÃ¡ch chiáº¿t tÃnh, dá»± tháº§u phá»¥c vá»¥ cho viá»c 
lÃ m tháº§u cá»§a doanh nghiá»p. 
â¢ CÃ³ kháº£ nÄng xuáº¥t sang Microsoft Excel vá»i Äáº§y Äá»§ cÃ´ng 
thá»©c, Äá»nh dáº¡ng,v.v.. ( Khi xuáº¥t sang Excel váº«n giá»¯ nguyÃªn 
Äá»nh dáº¡ng, cÃ´ng thá»©c trong tá»«ng Sheet vÃ  cÃ´ng thá»©c liÃªn káº¿t 
giá»¯a cÃ¡c Sheet).
â¢ CÃ³ kháº£ nÄng láº¥y tiÃªn lÆ°á»£ng dá»± toÃ¡n tá»« báº¥t ká»³ 1 dá»± 
toÃ¡n nÃ o nhÆ° dá»± toÃ¡n 97 nÄm 1997,..nÄm 2007 hoáº·c tiÃªn lÆ°á»£ng 
lÃ m trÃªn Excel. 
â¢ CÃ³ kháº£ nÄng tháº©m Äá»nh cÃ´ng trÃ¬nh Äá» tÃ¬m ra sá»± sai 
lá»ch vá» khá»i lÆ°á»£ng, ÄÆ¡n giÃ¡. 
â¢ CÃ³ kháº£ nÄng káº¿t ná»i cÃ¡c tiÃªn lÆ°á»£ng láº¡i thÃ nh 1 tiÃªn 
lÆ°á»£ng duy nháº¥t. 
â¢ DÃ¹ng Äa ÄÆ¡n giÃ¡, Äa háº¡ng má»¥c trong 1 cÃ´ng trÃ¬nh mÃ  khÃ´ng 
cáº§n tÃ¡ch 1 háº¡ng má»¥c thÃ nh 1 file nhÆ° cÃ¡c pháº§n má»m dá»± toÃ¡n 
khÃ¡c. 
â¢ CÆ¡ sá» dá»¯ liá»u hiá»u chá»nh dá» dÃ ng, trá»±c quan vÃ  Äáº·c 
biá»t lÃ  cÃ³ Äá»§ ÄÆ¡n giÃ¡, Äá»nh má»©c cá»§a 64 Tá»nh, ThÃ nh phá». 
â¢ TÃnh bÃ¹ giÃ¡ nhiÃªn liá»u, bÃ¹ giÃ¡ ca mÃ¡y, cÆ°á»c váºn chuyá»n, 
tá»± Äá»ng váº½ biá»u Äá» tiáº¿n Äá» thi cÃ´ng ,ghi báº£n váº½ sang 
Autocad. 
â¢ Há» trá»£ ngÆ°á»i dÃ¹ng láºp cÃ´ng tÃ¡c Táº¡m tÃnh cÃ³ phÃ¢n tÃch 
Váºt tÆ°/ NhÃ¢n cÃ´ng/ MÃ¡y Äáº§y Äá»§, cho phÃ©p thÃªm váºt tÆ° má»i vÃ o 
cÆ¡ sá» dá»¯ liá»u Äá» dÃ¹ng cho nhiá»u cÃ´ng trÃ¬nhâ¦..
â¢ Gá»i quÃ½ khÃ¡ch bÃ¡o giÃ¡ pháº§n  má»m dá»± toÃ¡n G8.
 1.) Dá»± toÃ¡n G8 Amateur - 2011
Sá» cÃ´ng tÃ¡c  : 200
Sá» háº¡ng má»¥c : 01
GiÃ¡  : 1.000.000 (VND) ( Má»t triá»u Äá»ng )
2.) Dá»± toÃ¡n G8 Beginner - 2011
Sá» cÃ´ng tÃ¡c  : 300
Sá» háº¡ng má»¥c : 01
GiÃ¡  : 2.000.000 (VND) ( Hai triá»u Äá»ng )
3.) Dá»± toÃ¡n G8 Professional - 2011
Sá» cÃ´ng tÃ¡c  : 400
Sá» háº¡ng má»¥c : 01
GiÃ¡  : 3.000.000 (VND) ( Ba triá»u Äá»ng )
4.) Dá»± toÃ¡n G8 Enterprise - 2011
Sá» cÃ´ng tÃ¡c  : VÃ´ háº¡n
Sá» háº¡ng má»¥c : VÃ´ háº¡n
GiÃ¡  : 4.000.000 (VND) ( Bá»n triá»u Äá»ng )
QuÃ½ khÃ¡ch cÃ³ thá» hoÃ n toÃ n yÃªn tÃ¢m vÃ  tin tÆ°á»ng khi sá» dá»¥ng 
pháº§n má»m Dá»± toÃ¡n - Dá»± tháº§u G8 trong viá»c phÃ¢n tÃch vÃ  ÄÃ¡nh 
giÃ¡ káº¿t quáº£ cá»§a cÃ¡c cÃ´ng trÃ¬nh.
QuÃ½ khÃ¡ch cÃ³ thá» táº£i  bá» cÃ i pháº§n má»m Dá»± toÃ¡n G8 Express vá» 
dÃ¹ng thá»  ***MIá»N PHÃ*** táº¡i:
http://www.dutoang8.com/DownloadSF.asp
Táº£i vá» hÆ°á»ng dáº«n qua VIDEO:
http://www.dutoang8.com/Video.asp
Má»i ÄÃ³ng gÃ³p, yÃªu cáº§u há» trá»£ ká»¹ thuáºt cá»§a quÃ½ vá» xin vui 
lÃ²ng gá»i vá» Äá»a chá»:
CÃ´ng Ty Cá» Pháº§n TÆ° Váº¥n Äáº§u TÆ° XÃ¢y Dá»±ng AN VIá»T
75 - Nguyá»n VÄn LÆ°á»£ng - PhÆ°á»ng 17 - GÃ² Váº¥p - Tp.HCM.
PhÃ²ng Kinh Doanh
LÃª Thanh SÆ¡n
Hotline: 0168.314.8282 - 0822238663
Email : thanh...@anviet.edu.vn
HÃ£y gá»i hoáº·c nháº¯n tin cho tÃ´i dÃ¹ quÃ½ khÃ¡ch á» báº¥t cá»© nÆ¡i 
ÄÃ¢u, vÃ o báº¥t cá»© thá»i gian nÃ o.
TrÃ¢n trá»ng cÃ¡m Æ¡n quÃ½ khÃ¡ch hÃ ng ÄÃ£ quan tÃ¢m!

cgraph callees availability

Re: cgraph callees availability

Re: cgraph callees availability

Re: cgraph callees availability

Re: cgraph callees availability

Re: cgraph callees availability

Re: RFC: [GUPC] UPC-related changes

Validity of asm transformation with "m" reference

Re: viewcvs: Python error

Re: Validity of asm transformation with "m" reference

Re: Validity of asm transformation with "m" reference

Re: viewcvs: Python error

gcc-4.6-20110701 is now available

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

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

15 matches

Site Navigation

Mail list logo

Footer information