Re: Fix PR60644

2014-04-09 Thread Alexander Ivchenko
AM >> To: Iyer, Balaji V >> Cc: Alexander Ivchenko; Richard Biener; GCC Patches >> Subject: Re: Fix PR60644 >> >> On Wed, Apr 09, 2014 at 01:23:59PM +, Iyer, Balaji V wrote: >> > >> > >> > > -Original Message- >> >

RE: Fix PR60644

2014-04-09 Thread Iyer, Balaji V
> -Original Message- > From: Jakub Jelinek [mailto:ja...@redhat.com] > Sent: Wednesday, April 9, 2014 9:29 AM > To: Iyer, Balaji V > Cc: Alexander Ivchenko; Richard Biener; GCC Patches > Subject: Re: Fix PR60644 > > On Wed, Apr 09, 2014 at 01:23:59PM +00

Re: Fix PR60644

2014-04-09 Thread Jakub Jelinek
On Wed, Apr 09, 2014 at 01:23:59PM +, Iyer, Balaji V wrote: > > > > -Original Message- > > From: Jakub Jelinek [mailto:ja...@redhat.com] > > Sent: Wednesday, April 9, 2014 8:06 AM > > To: Alexander Ivchenko > > Cc: Richard Biener; GCC Patches;

RE: Fix PR60644

2014-04-09 Thread Iyer, Balaji V
> -Original Message- > From: Jakub Jelinek [mailto:ja...@redhat.com] > Sent: Wednesday, April 9, 2014 8:06 AM > To: Alexander Ivchenko > Cc: Richard Biener; GCC Patches; Iyer, Balaji V > Subject: Re: Fix PR60644 > > On Wed, Apr 09, 2014 at 03:46:13PM +0400,

Re: Fix PR60644

2014-04-09 Thread Jakub Jelinek
On Wed, Apr 09, 2014 at 03:46:13PM +0400, Alexander Ivchenko wrote: > ping.. I guess it really depends on whether the libcilkrts sources are going to be (semi?)regularly imported from some upstream repository or not, and if the upstream is willing to accept these changes. The alternative is to mo

Re: Fix PR60644

2014-04-09 Thread Alexander Ivchenko
ping.. 2014-04-04 15:28 GMT+04:00 Alexander Ivchenko : > 2014-04-04 14:19 GMT+04:00 Richard Biener : >> On Fri, Apr 4, 2014 at 12:03 PM, Alexander Ivchenko >> wrote: >>> *ping* >> >> I wonder whether this is consistend between compilers (note GCC is not >> upstream here?). So eventually all pla

Re: Fix PR60644

2014-04-04 Thread Alexander Ivchenko
2014-04-04 14:19 GMT+04:00 Richard Biener : > On Fri, Apr 4, 2014 at 12:03 PM, Alexander Ivchenko > wrote: >> *ping* > > I wonder whether this is consistend between compilers (note GCC is not > upstream here?). So eventually all places should be ANDROID || __ANDROID__? > I checked that gcc-4.[67

Re: Fix PR60644

2014-04-04 Thread Richard Biener
On Fri, Apr 4, 2014 at 12:03 PM, Alexander Ivchenko wrote: > *ping* I wonder whether this is consistend between compilers (note GCC is not upstream here?). So eventually all places should be ANDROID || __ANDROID__? Richard. > --Alexander > > 2014-03-27 13:43 GMT+04:00 Alexander Ivchenko : >> A

Re: Fix PR60644

2014-04-04 Thread Alexander Ivchenko
*ping* --Alexander 2014-03-27 13:43 GMT+04:00 Alexander Ivchenko : > Adding Balaji. > > --Alexander > > 2014-03-26 18:56 GMT+04:00 Alexander Ivchenko : >> Hi, >> >> In gcc/config/linux-android.h we have "builtin_define ("__ANDROID__");" >> So "ANDROID" as in libcilkrts now is not the correct macr

Re: Fix PR60644

2014-03-27 Thread Alexander Ivchenko
Adding Balaji. --Alexander 2014-03-26 18:56 GMT+04:00 Alexander Ivchenko : > Hi, > > In gcc/config/linux-android.h we have "builtin_define ("__ANDROID__");" > So "ANDROID" as in libcilkrts now is not the correct macro to check. > > Bootstrapped and passed cilk testsuite on x86_64-unknown-linux-gn

Fix PR60644

2014-03-26 Thread Alexander Ivchenko
Hi, In gcc/config/linux-android.h we have "builtin_define ("__ANDROID__");" So "ANDROID" as in libcilkrts now is not the correct macro to check. Bootstrapped and passed cilk testsuite on x86_64-unknown-linux-gnu. diff --git a/libcilkrts/ChangeLog b/libcilkrts/ChangeLog index eb0d6ec..65efef0 100