RFC: [GUPC] UPC-related changes

2010-07-07 Thread Gary Funck
FYI, over the course of the next week/so, I will post UPC-related changes to the gcc-patches mailing list, for review. The goal is to make the necessary fixes/changes, based upon review feedback, that need to be made prior to merging the GUPC branch into the GCC trunk. Email describing the chang

Re: Error in GCC documentation page

2010-07-07 Thread Nils Schlemminger
Am 08.07.2010 00:56, schrieb Jonathan Wakely: The usage is correct in "standardese" and English. My dictionary gives one definition of "integral" as "denoting a number that is an integer". Thats correct but not all non native speaker know that. The word integer is more common. Cheers Nils

Re: Error in GCC documentation page

2010-07-07 Thread Dave Korn
On 07/07/2010 23:56, Jonathan Wakely wrote: > On 7 July 2010 19:12, Paolo Carlini wrote: >> On 07/07/2010 08:02 PM, Trevor Smedley wrote: >>> On the page http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html the term >>> "integral" is used twice in the section " Built-in Function: long >>> __buil

Re: Error in GCC documentation page

2010-07-07 Thread Jonathan Wakely
On 7 July 2010 19:12, Paolo Carlini wrote: > On 07/07/2010 08:02 PM, Trevor Smedley wrote: >> On the page http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html the term >> "integral" is used twice in the section " Built-in Function: long >> __builtin_expect (long exp, long c)", where what is inte

Re: Error in GCC documentation page

2010-07-07 Thread Paolo Carlini
On 07/07/2010 08:02 PM, Trevor Smedley wrote: > On the page http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html the term > "integral" is used twice in the section " Built-in Function: long > __builtin_expect (long exp, long c)", where what is intended is "integer". > I'm not a native English

Error in GCC documentation page

2010-07-07 Thread Trevor Smedley
On the page http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html the term "integral" is used twice in the section " Built-in Function: long __builtin_expect (long exp, long c)", where what is intended is "integer". Trevor Smedley

Re: [trans-mem] __sync_add_and_fetch_8 on ia32

2010-07-07 Thread Richard Henderson
On 07/07/2010 08:51 AM, Aldy Hernandez wrote: > * configure.ac: Call LIBITM_CHECK_64BIT_SYNC_BUILTINS. > * beginend.cc (begin_transaction): If 64-bit sync builtins are not > available, use pthread mutexes. > * acinclude.m4 (LIBITM_CHECK_64BIT_SYNC_BUILTINS): New. > * c

Re: [trans-mem] __sync_add_and_fetch_8 on ia32

2010-07-07 Thread Aldy Hernandez
> > ... a slightly more sophisticated variant of b) would be using > > uint64_t for 64-bit targets and uint32_t for 32-bit targets, should > > make everybody happy. > > There's a correctness issue in the library interface -- there's no > clean way to handle that value overflowing. Rather than mak

Re: question about if_marked construct

2010-07-07 Thread Richard Guenther
On Tue, Jul 6, 2010 at 6:12 PM, Tom de Vries wrote: > Hi Richard, > >>> I can image a few ways to go from here: >>> - leave as is, fix this when it really bothers us (risk: exchange a known >>> problem for unknown hard-to-debug and/or hard-to-reproduce problems) >>> - instrument if_marked function

no_instrument_function attribute ignored by -Os

2010-07-07 Thread Groleo Marius
Hi, I tried using -finstrument-functions and -Os flags at the same time but the compiled test program segfaults due to recursive calls: $> gcc -g -Os -finstrument-functions ptrace.c && ./a.out Segmentation fault (core dumped) $> gdb a.out core #0 0x080485b7 in __cyg_profile_func_enter (this_fn=0