Re: My current idea for improving libgomp
On Tue, May 03, 2011 at 11:27:15AM +0900, Sho Nakatani wrote: > In my opinion, even tied task needs user-level thread for scheduling. I don't think so. Of course you need some data structure for each task, but having to allocate (even if from cache) a separate stack for each task is a significant runtime cost, and if you ever want to deschedule a task and change to another one, you either need to code your own swapcontext-ish target specific stuff, or use setcontext/swapcontext with its overhead and limitations and problems. For tied tasks that are tied to a particular thread anyway and can't be moved elsewhere I don't see what the additional overhead would buy you, for untied tasks of course that is different. > Also, it could be difficult to implement untied task without user-level > thread. Sure, but the overhead should be IMHO limited to untied tasks. > So, implementing user-level thread for tied task will keep simplicity > of task scheduler > since libgomp will have untied task implementation in the future. Will have it only if it is found to be actually beneficial. > One global task queue which libgomp currently uses would be one of > the biggest defeats. So I would first like to make new data structures > including user-level threads with their private queues. I don't see why you need user-level threads for having private queues, you can very well have the private queues for each kernel thread instead. Jakub
Re: Syncing with Launchpad Bug Tracker
On 27/04/11 18:29, Deryck Hodge wrote: I work at Canonical on Launchpad and am trying to setup syncing between our bug tracker and the GCC bug tracker. Specifically, we want to enable comment syncing between linked bugs on our trackers and back links from your Bugzilla to the Launchpad bug. Currently we only sync status and importance from your tracker to ours. We need credentials for an account on your tracker to setup this additional syncing. If we had such credentials, we would sync comments and back links only if a Launchpad bug is linked to a GCC Bugzilla bug. We store these credentials in private configs on Launchpad. We have this setup for a number of other trackers. The Mozilla Bugzilla comes to mind as a tracker we do this with already. Will it be possible to post comments to Launchpad, and not have them automatically posted to bugzilla? I sometimes post Linaro-specific details to the Launchpad bug which would be meaningless noise in upstream bugzilla. The bug is linked because the problem is the same, but typically the source-base is different, and/or we want to add additional tracking details, or whatever. e.g. I don't think bugzilla readers are interested in a comment like "Bug targeted at Linaro x.x release", or "Patch committed to lp:gcc-linaro/4.5 revision 99456". Andrew
Re: Syncing with Launchpad Bug Tracker
On 3 May 2011 10:51, Andrew Stubbs wrote: > On 27/04/11 18:29, Deryck Hodge wrote: >> >> I work at Canonical on Launchpad and am trying to setup syncing >> between our bug tracker and the GCC bug tracker. Specifically, we >> want to enable comment syncing between linked bugs on our trackers and >> back links from your Bugzilla to the Launchpad bug. Currently we only >> sync status and importance from your tracker to ours. We need >> credentials for an account on your tracker to setup this additional >> syncing. If we had such credentials, we would sync comments and back >> links only if a Launchpad bug is linked to a GCC Bugzilla bug. We >> store these credentials in private configs on Launchpad. We have this >> setup for a number of other trackers. The Mozilla Bugzilla comes to >> mind as a tracker we do this with already. > > Will it be possible to post comments to Launchpad, and not have them > automatically posted to bugzilla? > > I sometimes post Linaro-specific details to the Launchpad bug which would be > meaningless noise in upstream bugzilla. The bug is linked because the > problem is the same, but typically the source-base is different, and/or we > want to add additional tracking details, or whatever. > > e.g. I don't think bugzilla readers are interested in a comment like "Bug > targeted at Linaro x.x release", or "Patch committed to lp:gcc-linaro/4.5 > revision 99456". Completely agreed. I imagine the majority of comments on the downstream bug tracker are irrelevant for the upstream tracker. Patches and discussion of fixes should be submitted upstream as normal (to gcc-patches and/or in GCC bugzilla) not by syncing from a downstream tracker. Or if the patch isn't suitable for upstream, we don't want to know about it in GCC's bugzilla. It would be useful to see some examples of bugs in Mozilla's bugzilla which get synced with Launchpad bugs. Assuming only relevant comments get synced I think it would be useful, and it should be possible with a normal bugzilla user with no extra privileges (I don't think we want the Launchpad account to be able to modify arbitrary bugs, only its own.)
Re: Syncing with Launchpad Bug Tracker
Hi, all. On Tue, May 3, 2011 at 6:21 AM, Jonathan Wakely wrote: > On 3 May 2011 10:51, Andrew Stubbs wrote: >> On 27/04/11 18:29, Deryck Hodge wrote: >>> >>> I work at Canonical on Launchpad and am trying to setup syncing >>> between our bug tracker and the GCC bug tracker. Specifically, we >>> want to enable comment syncing between linked bugs on our trackers and >>> back links from your Bugzilla to the Launchpad bug. Currently we only >>> sync status and importance from your tracker to ours. We need >>> credentials for an account on your tracker to setup this additional >>> syncing. If we had such credentials, we would sync comments and back >>> links only if a Launchpad bug is linked to a GCC Bugzilla bug. We >>> store these credentials in private configs on Launchpad. We have this >>> setup for a number of other trackers. The Mozilla Bugzilla comes to >>> mind as a tracker we do this with already. >> >> Will it be possible to post comments to Launchpad, and not have them >> automatically posted to bugzilla? >> >> I sometimes post Linaro-specific details to the Launchpad bug which would be >> meaningless noise in upstream bugzilla. The bug is linked because the >> problem is the same, but typically the source-base is different, and/or we >> want to add additional tracking details, or whatever. >> >> e.g. I don't think bugzilla readers are interested in a comment like "Bug >> targeted at Linaro x.x release", or "Patch committed to lp:gcc-linaro/4.5 >> revision 99456". > > Completely agreed. I imagine the majority of comments on the > downstream bug tracker are irrelevant for the upstream tracker. > Patches and discussion of fixes should be submitted upstream as normal > (to gcc-patches and/or in GCC bugzilla) not by syncing from a > downstream tracker. Or if the patch isn't suitable for upstream, we > don't want to know about it in GCC's bugzilla. > > It would be useful to see some examples of bugs in Mozilla's bugzilla > which get synced with Launchpad bugs. > > Assuming only relevant comments get synced I think it would be useful, > and it should be possible with a normal bugzilla user with no extra > privileges (I don't think we want the Launchpad account to be able to > modify arbitrary bugs, only its own.) > The way this works is that once we have an account on your bug tracker, we will sync comments from the GCC Bugzilla to Launchpad and create a "see also" link to our bug on your bug. Without the account, we will keep the Launchpad bug in sync with your upstream tracker status only. With the account, we will pull comments from your bug into the Launchpad bug. We do not automatically sync any comments or attachments on the Launchpad bug back to the GCC bugzilla. We do provide a "Reply on GCC Bugzilla" link on imported comments, so someone can watch the activity on the Launchpad bug and comment upstream from our bug if they need to do so. If someone does this, the comment from Launchpad is listed as from the user "Launchpad" (or whatever we call the Launchpad account on your tracker that I setup), and the comment also has "Foo Bar added the following comment to Launchpad bug report XXX" at the top of the comment. Some examples: == Typical Bug Linked with Imported Upstream Comments == Launchpad: https://bugs.launchpad.net/firefox/+bug/394912 Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=488605 == Bug Linked where Launchpad users commented upstream == Launchpad: https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/10910?comments=all Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=147419 I believe this will work in the way the covers everyones concerns. Please let me know if there are other concerns. If not, I would like to go ahead and set this up. Cheers, deryck -- Deryck Hodge https://launchpad.net/~deryck http://www.devurandom.org/
Re: Syncing with Launchpad Bug Tracker
Deryck Hodge writes: > I believe this will work in the way the covers everyones concerns. > Please let me know if there are other concerns. If not, I would like > to go ahead and set this up. Please go ahead. Thanks. Ian
Re: Integration of transactional memory support into a data-flow extension of OpenMP
Hi Ismail! My study mainly focuses on integration of transactional memory support into data-flow extension of OpenMP that is aiming increased expressiveness and performance while preserving the paradigms' properties. I am really happy to see people working with transactional memory. I will try to follow your work. My project combines development and research components and can be decomposed into 5 phases. 1. Study the compatibility of the transactional memory and OpenMP constructs in the transmem development branch of GCC and propose solutions to the possible technical difficulties. In the Velox project, one application named QuakeTM was using TM and OpenMP without problem but I know that the OpenMP was not used extensively. So probably you will find some problems. 2. Study the desgin and implementation of both data-flow (streaming) and transmem branches of GCC, interacting with their maintainers. I am not a maintainer (not yet at least) of the trans-mem branch but I know quite well TM and some part of implementation details in gcc. So if you post questions, I will try to answer them. Note : Just an example code from LeeTM for compatibility research of OpenMP and trans-mem . #define MEMSET _ITM_memsetW #define MEMCPY _ITM_memcpyRtWt #define BEGIN_TRANSACTION \ _ITM_beginTransaction (pr_instrumentedCode | pr_hasNoIrrevocable\ | pr_hasNoAbort) #define END_TRANSACTION \ _ITM_commitTransaction () Why did you use explicit calls to _ITM_* functions? why not using the __transaction semantic? // transaction body lee->layNextTrack(track, targ->private_buffer); Did you transactify accesses in this function? or does it use only MEMSET and MEMCPY? (I have tried LeeTM only one time and I can't remember implementation details.) There is not a big performance difference between our approach (OpenMP + trans-mem) and (pthreads + tinySTM). Interesting. Actually I am one of the developers of TinySTM and I am quite interested to see exact results. Good luck and feel free to ask questions. Patrick Marlier.
[google] Merged google/main and gcc-4_6-branch into google/gcc-4_6
This merge brings google/gcc-4_6 up to date with google/main rev 173286, minus rev 173258 (we found an issue with that revision that Chris is going to address). It also merged from gcc-4_6-branch rev 173305. Validated on x86_64. Attached are the list of changes brought in from google/main and gcc-4_6-branch. Diego. Merged revisions 172725,172736,172789,172874-172880,172951-172952,172987,172992,173003,173049,173148,173158-173165,173179-173180,173184,173186-173187,173196,173198,173209,173241,173254,173270-173271,173276,173286 via svnmerge from svn+ssh://gcc.gnu.org/svn/gcc/branches/google/main r172725 | davidxl | 2011-04-19 13:09:41 -0400 (Tue, 19 Apr 2011) | 1 line fix potential div by zero error r172736 | martinthuresson | 2011-04-19 17:44:37 -0400 (Tue, 19 Apr 2011) | 5 lines 2011-04-19 Martin Thuresson * libgcov.c (gcov_version): Do not access filename in struct generated from different version. r172789 | eraman | 2011-04-20 15:11:01 -0400 (Wed, 20 Apr 2011) | 5 lines 2011-04-19 Easwaran Raman * gcc/gcc.c (asm_options): Pass --save-temps to assembler. r172874 | davidxl | 2011-04-22 16:32:04 -0400 (Fri, 22 Apr 2011) | 3 lines Initialized merge tracking via "svnmerge" with revisions "1-172873" from svn+ssh://davi...@gcc.gnu.org/svn/gcc/branches/lw-ipo r172875 | davidxl | 2011-04-22 16:47:35 -0400 (Fri, 22 Apr 2011) | 3 lines Removed merge tracking for "svnmerge" for svn+ssh://davi...@gcc.gnu.org/svn/gcc/branches/lw-ipo r172876 | davidxl | 2011-04-22 16:48:31 -0400 (Fri, 22 Apr 2011) | 3 lines Initialized merge tracking via "svnmerge" with revisions "1-147116" from svn+ssh://davi...@gcc.gnu.org/svn/gcc/branches/lw-ipo r172877 | davidxl | 2011-04-22 16:53:25 -0400 (Fri, 22 Apr 2011) | 3 lines Removed merge tracking for "svnmerge" for svn+ssh://davi...@gcc.gnu.org/svn/gcc/branches/lw-ipo r172878 | davidxl | 2011-04-22 16:55:09 -0400 (Fri, 22 Apr 2011) | 3 lines Initialized merge tracking via "svnmerge" with revisions "1-172877" from svn+ssh://gcc.gnu.org/svn/gcc/branches/lw-ipo r172879 | davidxl | 2011-04-22 16:56:15 -0400 (Fri, 22 Apr 2011) | 3 lines Removed merge tracking for "svnmerge" for svn+ssh://gcc.gnu.org/svn/gcc/branches/lw-ipo r172880 | davidxl | 2011-04-22 16:56:54 -0400 (Fri, 22 Apr 2011) | 3 lines Initialized merge tracking via "svnmerge" with revisions "1-147116" from svn+ssh://gcc.gnu.org/svn/gcc/branches/lw-ipo r172951 | carrot | 2011-04-25 21:55:33 -0400 (Mon, 25 Apr 2011) | 5 lines * gcc/config/arm/arm.c (SHORTEST_FAR_JUMP_LENGTH): New constant. (estimate_function_length): New function. (thumb_far_jump_used_p): No far jump is needed in short function. r172952 | davidxl | 2011-04-26 00:38:46 -0400 (Tue, 26 Apr 2011) | 1 line Port LIPO support to google/main r172987 | eraman | 2011-04-26 17:14:31 -0400 (Tue, 26 Apr 2011) | 6 lines 2011-04-26 Easwaran Raman * gcc/gcc.c (asm_options): Pass --save-temps to assembler when invoked with -save-temps= option. r172992 | lcwu | 2011-04-26 18:58:12 -0400 (Tue, 26 Apr 2011) | 1 line Port the implementation of -Wself-assign to google/main. r173003 | davidxl | 2011-04-26 20:20:53 -0400 (Tue, 26 Apr 2011) | 1 line backport 172978 172870 and 172848 to google/main r173049 | davidxl | 2011-04-27 19:26:52 -0400 (Wed, 27 Apr 2011) | 1 line Fix lipo regression with pid change r173148 | davidxl | 2011-04-28 20:31:58 -0400 (Thu, 28 Apr 2011) | 1 line LIPO regression test and bug fixes r173158 | dnovillo | 2011-04-29 10:33:32 -0400 (Fri, 29 Apr 2011) | 15 lines 2011-04-27 Silvius Rus * doc/invoke.texi (fno-strict-enum-precision): Document. * gimplify.c (gimplify_switch_expr): If -fno-strict-enum-precision is given, do not consider enum types. * tree-vrp.c (stmt_interesting_for_vrp): If -fno-strict-enum-precision is given, do not look at enum types. 2011-04-27 Silvius Rus * g++.dg/other/no-strict-enum-precision-1.C: New. * g++.dg/other/no-strict-enum-precision-2.C: New. * g++.dg/other/no-strict-enum-precision-3.C: New. r173159 | dnovillo | 2011-04-29 10:34:15 -0400 (Fri, 29 Apr 2011) | 33 lines cp/ChangeLog.google-main 2011-04-27 Le-Chun Wu * cp-tree.h (LOOKUP_EXPLICIT_TMPL_ARGS): Define. * call.c (build_new_function_call): Set it for TEMPLATE_ID_EXPRs. (build_over_call): Use it to determine whether to emit a NULL warning for template function instantiations. (build_new_method_call): Set LOOKUP_EXPLICIT_TMPL_ARGS if EXPLICIT_TARGS is set. testsuite/ChangeLog.google-main 2011-04-27 Le-Chun Wu
adding an argument for test execution in testsuite
Is it possible to add an argument to the test in the execution phase of the testsuite? I am looking into some test cases where number of threads to run must be provided on the invocation line of the test if not specified during the test compilation. Something that is similar to "dg-skip-if" syntax but would add a run-time option if there is a match. Thanks, Nenad
Re: Integration of transactional memory support into a data-flow extension of OpenMP
On Tue, 2011-05-03 at 23:09 +0200, ismail kuru wrote: > > > On 3 May 2011 17:02, Patrick Marlier wrote: > Hi Ismail! > > > My study mainly focuses on integration of > transactional memory support > into data-flow extension of OpenMP that is > aiming increased expressiveness and performance while > preserving the > paradigms' properties. > > > I am really happy to see people working with transactional > memory. I will try to follow your work. > > > ++ Thanks a lot for your attention to my project. Yes , it also > really makes me happy to have people interested in Transactional > memory and my project. > > My project combines development and research > components and can be > decomposed into 5 phases. > > 1. Study the compatibility of the transactional memory > and OpenMP > constructs in the > transmem development branch of GCC and propose > solutions to the possible > technical > difficulties. > > > In the Velox project, one application named QuakeTM was using > TM and OpenMP without problem but I know that the OpenMP was > not used extensively. So probably you will find some problems. > > ++ I have not worked on QuakeTM before . Thanks a lot for > suggestion. > > 2. Study the desgin and implementation of both > data-flow (streaming) and > transmem branches > of GCC, interacting with their maintainers. > > > I am not a maintainer (not yet at least) of the trans-mem > branch but I know quite well TM and some part of > implementation details in gcc. So if you post questions, I > will try to answer them. > > ++ Having contact with some experienced people on > Transactional Memory is really so important for me . It would > be great for me. > > > Note : Just an example code from LeeTM for > compatibility research of > OpenMP and trans-mem . > > #define MEMSET _ITM_memsetW > #define MEMCPY _ITM_memcpyRtWt > #define BEGIN_TRANSACTION \ > _ITM_beginTransaction (pr_instrumentedCode | > pr_hasNoIrrevocable\ > | pr_hasNoAbort) > > #define END_TRANSACTION \ > _ITM_commitTransaction () > > > Why did you use explicit calls to _ITM_* functions? why not > using the __transaction semantic? > ++ I was trying to do experiments with different passing > parameters (instrumentedCode , uninstrumentedCode, > hasNoAbort, hasNoRetry, hasNoIrrevocable,doesGoIrrevocabl ) to > "_ITM_beginTransaction" and try to scale the compatibility > with ++OpenMP constructs. I have also used "__transaction" > semantic. There is no problem. This is what I have put here. > >// transaction body >lee->layNextTrack(track, > targ->private_buffer); > > > Did you transactify accesses in this function? or does it use > only MEMSET and MEMCPY? > (I have tried LeeTM only one time and I can't remember > implementation details.) > > > ++ I have tried both. I am having problems on this part because of not > being experienced and I think I have to make experiments again on > LeeTM. > ++ First of all, MEMCPY and MEMSET functions do not include any > transaction identifier (id) and transactions inside the LeeTM fails > during transactional access to the memory. I think this case is also > for tinySTM-0.9.9 and tinySTM-1.0. > > > ++ tinySTM-0.9.9 has mem access functions with transaction handlers as > the following > ++stm_word_t stm_load(stm_tx_t *tx, volatile stm_word_t *addr); > ++void stm_store(stm_tx_t *tx, volatile stm_word_t *addr, stm_word_t > value); > ++void stm_store2(stm_tx_t *tx, volatile stm_word_t *addr, stm_word_t > value, stm_word_t mask); > > > ++but tinySTM-1.0 does not . Your opinions on these different version > of mem-access functions would be great. > > ++My idea to convert from one version of mem-access function to > another is as the following: > > > ++ I think I have to make some explicit function calls as the > following: > ++ _ITM_transaction * td = _ITM_getTransaction(); > ++int doWhat = > _ITM_beginTransaction(td,pr_instrumentedCode,&txn_start_loc); > ++
Re: adding an argument for test execution in testsuite
Nenad Vukicevic writes: > Is it possible to add an argument to the test in the > execution phase of the testsuite? I am looking into > some test cases where number of threads to run must > be provided on the invocation line of the test if not > specified during the test compilation. Something that > is similar to "dg-skip-if" syntax but would add a run-time > option if there is a match. There is no support for passing options to a test in the dg framework. You would have to write your own Tcl code to do that. Note that such tests are somewhat discouraged because not all remote execution environments support passing command line arguments. It's OK to do it if the command line argument is optional or if the test can never work on an embedded system anyhow. Ian
gcc-4.4-20110503 is now available
Snapshot gcc-4.4-20110503 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110503/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 173344 You'll find: gcc-4.4-20110503.tar.bz2 Complete GCC (includes all of below) MD5=620d24c816efd9455faf595334eaa9b2 SHA1=6825aa2418ac7dee4bc3ef2126296e33254e5230 gcc-core-4.4-20110503.tar.bz2C front end and core compiler MD5=2c3caa4633f7d35ee984ff412432fd3f SHA1=65f538b60e424ec7c9bcb6fb5b7b499396993580 gcc-ada-4.4-20110503.tar.bz2 Ada front end and runtime MD5=4bd7c6fa7ce7816b2c787de325bc68e2 SHA1=0b23fbcea84c6a009178669c2c19e941a9f66a5e gcc-fortran-4.4-20110503.tar.bz2 Fortran front end and runtime MD5=ba8ca64ae845932798915da7908cc74b SHA1=64fb503bf3e2e9eb7750c099dbdd8be4496ada2a gcc-g++-4.4-20110503.tar.bz2 C++ front end and runtime MD5=b172279012ca51be2c2278ab01bd047f SHA1=d7dbb6d4017cc0c9d2096659d1204c0956c1c56f gcc-go-4.4-20110503.tar.bz2 Go front end and runtime MD5=611099c3e236905f203087eb92e34e4f SHA1=5d019fb5409e729d7e3b23d930d18dc2daf388ff gcc-java-4.4-20110503.tar.bz2Java front end and runtime MD5=544e526dc868e68b4893b34857509664 SHA1=072815edbd84a358d63db526015dc96d0d313e21 gcc-objc-4.4-20110503.tar.bz2Objective-C front end and runtime MD5=478166bc7283ca0176b7d0bca8721f87 SHA1=daf3277c83734f20f42e45541c4514e7f5d4ccad gcc-testsuite-4.4-20110503.tar.bz2 The GCC testsuite MD5=0c3ba2885f64dc37d239cf770aaf4ff2 SHA1=a8aabd3c20c83b33c359c56682596d9d0b8cf303 Diffs from 4.4-20110426 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
Detecting global pointers
I am writing a gcc plugin and am trying to detect if a value assigned by a
function call, is a global variable or not. Unfortunately, all calls to
'is_global_var' with a DECL type are returning false.
My pass executes after alias analysis, and ipa analysis. The
cfun->gimple_df->ipa_pta is set to true, so I know the pta analysis should have
resolved global information.
Plugin code:
if (is_gimple_call(stmt))
{
gimple_debug_bb(stmt);
tree lhs = gimple_call_lhs(stmt);
if (lhs && is_global_var(SSA_NAME_VAR(lhs)))
printf("Global detected\n");
}
Source code (in Go):
package main
type T struct {id int}
var myglobal *T;
func fn() *T {
myglobal = new(T); // Should be detected as global
return myglobal;
}
func main() {
t := fn();
}
Basic Block dump as my plugin code executes for function 'fn':
:
# .MEM_4 = VDEF <.MEM_3(D)>
main.myglobal.13_1 = __go_new_nopointers (4);
# .MEM_5 = VDEF <.MEM_4>
main.myglobal = main.myglobal.13_1;
# VUSE <.MEM_5>
D.186_2 = main.myglobal;
return D.186_2;
Any insight would be helpful.
Thanks!
-Matt
printf issue
Hi,
My image was built with arm-none-eabi-xxx tool chain(2008-q3). And the compile
options as follow.
FCFLAG = -msoft-float -mfloat-abi=soft -mno-apcs-float
FAFLAG = -msoft-float -mfloat-abi=soft
CFLAG = -mcpu=cortex-a8 $(FCFLAG) -Wall -Wpointer-arith -Wstrict-prototypes
-Winline -Wundef -mapcs -g -O0 -ffunction-sections -fdata-sections
-fno-exceptions -I.
AFLAG = -mcpu=cortex-a8 $(FAFLAG) -Wall -Wundef -mapcs -g -O0 -I. -lc
-nostartfiles -T src/mx53_iram.ld
In the main.c file , I used printf("%f",1.0f); to print a float number but the
output is 0..
Can anybody help me to figure that out, pls?
BR
Jerry
