RFC: [GUPC] UPC-related changes
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 changes will be grouped according to a general area (front-end, make/configure, debugging info., middle-end, etc.). The first email, describing front-end changes is here: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00628.html - Gary
Re: Error in GCC documentation page
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
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 >>> __builtin_expect (long exp, long c)", where what is intended is "integer". >>> >> I'm not a native English speaker, and would like to know more about that >> use, but can't be *that* bad if you can find it also in the ISO C++ >> Standard ;) > > The usage is correct in "standardese" and English. > My dictionary gives one definition of "integral" as "denoting a number > that is an integer". OTOH, the more common everyday meaning of "integral" is "built-in". Which in the context might be a little confusing! :) cheers, DaveK
Re: Error in GCC documentation page
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 intended is "integer". >> > I'm not a native English speaker, and would like to know more about that > use, but can't be *that* bad if you can find it also in the ISO C++ > Standard ;) The usage is correct in "standardese" and English. My dictionary gives one definition of "integral" as "denoting a number that is an integer".
Re: Error in GCC documentation page
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 speaker, and would like to know more about that use, but can't be *that* bad if you can find it also in the ISO C++ Standard ;) Paolo.
Error in GCC documentation page
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
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. > * config.h.in: Regenerate. > * configure: Regenerate. Ok. r~
Re: [trans-mem] __sync_add_and_fetch_8 on ia32
> > ... 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 make the
> library interface way more complex, it seemed far easier to simply
> use a 64-bit value, which we simply assume won't overflow.
>
> I'd be fine with -m586 (which is how things will get built on e.g.
> Fedora), but that isn't going to help other 32-bit targets that miss
> that operation. We'll need a configure test and a mutex if needed.
Sorry to have dropped the ball on this for so long, but 32-bit problems
weren't too high on my priority list :-).
I have added configury magic to check for 64-bit sync builtins. If
there are no 64-bit builtins, we implement the global thread id with
POSIX threads.
Alas, this surfaced some seemingly unrelated runtime problems in 32-bit
land, which I'll tackle next.
At least we can now build and run (some) tests. Yay!
Tested on x86-64 with: RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
OK for branch?
* 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.
* config.h.in: Regenerate.
* configure: Regenerate.
Index: configure.ac
===
--- configure.ac(revision 161318)
+++ configure.ac(working copy)
@@ -216,6 +216,7 @@ CFLAGS="$save_CFLAGS $XCFLAGS"
# Check for __sync_val_compare_and_swap, but only after the target has
# had a chance to set XCFLAGS.
LIBITM_CHECK_SYNC_BUILTINS
+LIBITM_CHECK_64BIT_SYNC_BUILTINS
# Cleanup and exit.
CFLAGS="$save_CFLAGS"
Index: beginend.cc
===
--- beginend.cc (revision 161318)
+++ beginend.cc (working copy)
@@ -84,6 +84,10 @@ GTM::gtm_transaction::operator delete(vo
thr->free_tx[idx] = tx;
}
+#ifndef HAVE_64BIT_SYNC_BUILTINS
+static pthread_mutex_t global_tid_lock = PTHREAD_MUTEX_INITIALIZER;
+#endif
+
uint32_t
GTM::gtm_transaction::begin_transaction (uint32_t prop, const gtm_jmpbuf *jb)
{
@@ -99,7 +103,13 @@ GTM::gtm_transaction::begin_transaction
tx->prev = gtm_tx();
if (tx->prev)
tx->nesting = tx->prev->nesting + 1;
+#ifdef HAVE_64BIT_SYNC_BUILTINS
tx->id = __sync_add_and_fetch (&global_tid, 1);
+#else
+ pthread_mutex_lock (&global_tid_lock);
+ tx->id = ++global_tid;
+ pthread_mutex_unlock (&global_tid_lock);
+#endif
tx->jb = *jb;
set_gtm_tx (tx);
Index: acinclude.m4
===
--- acinclude.m4(revision 161318)
+++ acinclude.m4(working copy)
@@ -12,6 +12,20 @@ AC_DEFUN([LIBITM_CHECK_SYNC_BUILTINS], [
[Define to 1 if the target supports __sync_*_compare_and_swap])
fi])
+dnl Check whether the target supports 64-bit __sync_*_compare_and_swap.
+AC_DEFUN([LIBITM_CHECK_64BIT_SYNC_BUILTINS], [
+ AC_CACHE_CHECK([whether the target supports 64-bit
__sync_*_compare_and_swap],
+libitm_cv_have_64bit_sync_builtins, [
+ AC_TRY_LINK([#include ],
+[uint64_t foo, bar;
+ bar = __sync_val_compare_and_swap(&foo, 0, 1);],
+libitm_cv_have_64bit_sync_builtins=yes,
+libitm_cv_have_64bit_sync_builtins=no)])
+if test $libitm_cv_have_64bit_sync_builtins = yes; then
+ AC_DEFINE(HAVE_64BIT_SYNC_BUILTINS, 1,
+ [Define to 1 if the target supports 64-bit
__sync_*_compare_and_swap])
+ fi])
+
dnl Check whether the target supports hidden visibility.
AC_DEFUN([LIBITM_CHECK_ATTRIBUTE_VISIBILITY], [
AC_CACHE_CHECK([whether the target supports hidden visibility],
Re: question about if_marked construct
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 functions like the one for value_expr_for_decl to >>> assert if the from field is live and the to field is not live, and fix >>> the >>> asserts >>> - extend garbage colllector to handle the problematic case (problem: more >>> runtime and/or memory usage for garbage collection) >>> Any suggestions on which way to go? >> >> Or make sure to walk all if_marked roots last (isn't the problem an >> ordering one only?) > > That is already done. The problem is not what happens after that walk, but > during that walk. The code at that point assumes that the set of marked > non-hashtable-entry objects is already stable, while the problematic > if_marked functions have the effect that that set is enlarged during that > walk. Hm, indeed - I know that this happens and it is not easy to avoid. > If we want to fix that in the garbage collector, we could walk the > problematic if_marked roots iteratively (without deleting unmarked entries), > until fixed point is reached. After that we would walk (and delete unmarked > entries) for both problematic and normal if_marked roots. However, I don't > have good idea how we can iterate to fixed-point efficiently. Me neither. I suppose it would be nice to avoid the situation by dropping if_marked from problematic hashes. Can we at least somehow figure out which one are those? (for example by doing inefficient iteration with ENABLE_CHECKING and ICEing if the 2nd iteration changes anything?) Richard. > Tom >
no_instrument_function attribute ignored by -Os
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=0x80485a2,
call_site=0x80485bc) at ptrace.c:15
#1 0x080485bc in __cyg_profile_func_enter (this_fn=0x80485a2,
call_site=0x80485bc) at ptrace.c:15
#2 0x080485bc in __cyg_profile_func_enter (this_fn=0x80485a2,
call_site=0x80485bc) at ptrace.c:15
#3 0x080485bc in __cyg_profile_func_enter (this_fn=0x80485a2,
call_site=0x80485bc) at ptrace.c:15
#4 0x080485bc in __cyg_profile_func_enter (this_fn=0x80485a2,
call_site=0x80485bc) at ptrace.c:15
I disabled function instrumentation for __cyg_profile_func_enter using
__attribute__ ((no_instrument_function))
but it looks like it's ignored.
Does -Os behavior specifically ignores the 'no_instrument_function' attribute ?
Taking -Os out makes it work:
$> gcc -g -finstrument-functions ptrace.c && ./a.out
enter 0x8048552
enter 0x804851f
enter 0x80484ec
enter 0x80484be
exit 0x80484be
exit 0x80484ec
exit 0x804851f
enter 0x80484be
exit 0x80484be
exit 0x8048552
--
Regards!
http://groleo.wordpress.com/
#define _GNU_SOURCE
#include
#include
#ifdef __cplusplus
extern "C" {
#endif
/* called upon function entry */
void
__attribute__ ((no_instrument_function))
__cyg_profile_func_enter(void *this_fn, void *call_site)
{
fprintf(stdout, "enter %p\n", this_fn);
}
/* called upon function exit */
void
__attribute__ ((no_instrument_function))
__cyg_profile_func_exit(void *this_fn, void *call_site)
{
fprintf(stdout, "exit %p\n", this_fn);
}
void func_c( void )
{
return;
}
void func_b( void )
{
func_c();
}
void func_a( void )
{
func_b();
}
#ifdef __cplusplus
}
#endif
int main()
{
func_a();
func_c();
}
