Mark Mitchell | 1 May 04:30 2011

GCC Release Management

The GCC Steering Committee appointed me to the role of GCC Release
Manager on March 22, 2000, as part of the GCC 3.0 release cycle.  Eleven
years and umpteen releases later, it's time for me to relinquish that
position.  I am just as interested in GCC as ever, but I simply no
longer have the time to contribute to GCC on a day-to-day basis.

Fortunately, in 2008, the GCC SC added three co-RMs: Jakub Jelinek,
Joseph Myers, and Richard Guenther.  The three of them have shouldered
the majority of the load over the past couple of years.  The SC
collectively and I personally have every confidence in their ability to
do continue onwards.  In fact, I have no doubt that they will do a
better job together of managing future releases than I did.

During my tenure as RM, I received the support, kind words, and
constructive criticism of many, many people -- far too many to name.  I
am very grateful for all of that and, more generally, for having had the
opportunity to be involved in such an important open-source project.

Thank you,

--

-- 
Mark Mitchell
CodeSourcery / Mentor Graphics
mark <at> codesourcery.com
(650) 331-3385 x713

gccadmin | 1 May 21:47 2011
Picon

gcc-4.3-20110501 is now available

Snapshot gcc-4.3-20110501 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20110501/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 173234

You'll find:

 gcc-4.3-20110501.tar.bz2             Complete GCC (includes all of below)

  MD5=9ffb7d2f6f907f711d16aa1e9c3ed4ab
  SHA1=4aa24abb6bd49017d0226137ccf5ed42b6780eb6

 gcc-core-4.3-20110501.tar.bz2        C front end and core compiler

  MD5=b736fcfd9655ef29deeab7e575e1c10e
  SHA1=82c8998e7ecd269ddc2c1f860059aa24b567d21b

 gcc-ada-4.3-20110501.tar.bz2         Ada front end and runtime

  MD5=440f23804980b0922a6932af6dfaf6dd
  SHA1=2abfc6252e4aaacdb4452f40fe9cb0e4886d3d78

 gcc-fortran-4.3-20110501.tar.bz2     Fortran front end and runtime

  MD5=ace02da49e2aeab2190dc54428564f1b
  SHA1=b9b3eabd10c609a8cb037fc8b5bb8301e59b77d6

 gcc-g++-4.3-20110501.tar.bz2         C++ front end and runtime
(Continue reading)

Gerald Pfeifer | 2 May 00:26 2011

Re: Syncing with Launchpad Bug Tracker

On Wed, 27 Apr 2011, Ian Lance Taylor wrote:
> Does any gcc maintainer object to setting this up?  It sounds like a
> good idea to me.

Indeed.  Having our bug tracking systems disconnected is one of the
weak spots free software (or Open Source) development is facing and
any such attempt to link systems more tightly is welcome.

Gerald

Sho Nakatani | 2 May 02:28 2011
Picon

Re: My current idea for improving libgomp

Hi,

I'm trying to make better libgomp implementation of task construct in
a GSoC project.
After reading several paper around OpenMP task feature, several
questions occurred to me.
I appreciate all of your answers. Even a few comments will do.

* Tell me good reference of OpenMP standards. What is referenced when
libgomp was implemented.
  I'm reading OpenMP Tutorial (
http://www.llnl.gov/computing/tutorials/openMP ).

* How should user-level and kernel-level threads be implemented?
  In my opinion, user-level threads should be a small data structure
with call-stack
  and kernel-level threads should be pthreads which are tied to CPUs
by sched_setaffinity() system call.
  (manpage says sched_setaffinity() is provided only in Linux, though..)

* Which interface (ABI) should be left in libgomp when I rewrite task feature?
  I guess I should be very careful since task construct is related to other ones
  like taskwait, barrier, and parallel.

Thanks,
--
Sho Nakatani

Laurynas Biveinis | 2 May 04:11 2011
Picon

Re: GCC Release Management

2011/5/1 Mark Mitchell <mark <at> codesourcery.com>:
> The GCC Steering Committee appointed me to the role of GCC Release
> Manager on March 22, 2000, as part of the GCC 3.0 release cycle.  Eleven
> years and umpteen releases later, it's time for me to relinquish that
> position.

Mark -

Thank you for your service as a RM during all those years.

--

-- 
Laurynas

Jakub Jelinek | 2 May 07:45 2011
Picon

Re: My current idea for improving libgomp

On Mon, May 02, 2011 at 09:28:52AM +0900, Sho Nakatani wrote:
> I'm trying to make better libgomp implementation of task construct in
> a GSoC project.

First of all, if you haven't started with the FSF assignment paperwork,
please do so, it takes a while.  See http://gcc.gnu.org/contribute.html

> * Tell me good reference of OpenMP standards. What is referenced when
> libgomp was implemented.

http://openmp.org/wp/openmp-specifications/

> * How should user-level and kernel-level threads be implemented?
>   In my opinion, user-level threads should be a small data structure
> with call-stack
>   and kernel-level threads should be pthreads which are tied to CPUs
> by sched_setaffinity() system call.
>   (manpage says sched_setaffinity() is provided only in Linux, though..)

For #pragma omp parallel and tied tasks you just want user-level ==
kernel-level thread as implemented in libgomp, with affinity only
done when requested by the user (GOMP_CPU_AFFINITY resp. on gomp-3_1-branch
also the to be implemented OMP_PROC_BIND env vars).

> * Which interface (ABI) should be left in libgomp when I rewrite task feature?

IMHO you don't want to rewrite the task support, just primarily investigate
various scheduling algorithms and attempt to implement some of them and
benchmark.

(Continue reading)

Georg-Johann Lay | 2 May 10:28 2011
Picon

Re: How to tell reload to properly store a register?

H.J. Lu schrieb:
> On Sat, Apr 30, 2011 at 6:18 AM, Georg-Johann Lay <avr <at> gjlay.de> wrote:
>> H.J. Lu schrieb:
>>> My target needs a scratch register to store a register in one register
>>> class
>>> and it needs to use memory to copy from one register class to another.
>>> I have store and reload_out patterns for those registers.  When reload
>>> tries to copy data from one register class to another, it just stores the
>>> register without using the proper reload_out pattern which has a scratch
>>> register.
>>>
>>> How can I tell reload to always use a scratch register when storing a
>>> register?
>> Did you define the TARGET_SECONDARY_RELOAD hook?
>>
> 
> I did. I have
> 
>   if (!in_p && MEM_P (x))
>     {
>       sri->icode = direct_optab_handler (reload_out_optab, mode);
>       return NO_REGS;
>     }
> 
> 
> Somehow, it isn't used when reloading
> 
> set (regclass1:SF) (regclass2:SF)

But in that case MEM_P is false, these are two REG_Ps.
(Continue reading)

Sho Nakatani | 3 May 04:27 2011
Picon

Re: My current idea for improving libgomp

Hi,

> First of all, if you haven't started with the FSF assignment paperwork,
> please do so, it takes a while.  See http://gcc.gnu.org/contribute.html

I've already started it. Thanks.

> For #pragma omp parallel and tied tasks you just want user-level ==
> kernel-level thread as implemented in libgomp, with affinity only
> done when requested by the user (GOMP_CPU_AFFINITY resp. on gomp-3_1-branch
> also the to be implemented OMP_PROC_BIND env vars).

In my opinion, even tied task needs user-level thread for scheduling.
I've read several paper related to task implementations. Many of task schedulers
have user-level thread with its own private queue. In order to prevent
contention of
task queue, it is good idea to let user-level threads have their own
private queue.
(I got this idea mostly from Section 3 of "Evaluation of OpenMP Task
Scheduling Strategies" by Nanos Group)

Also, it could be difficult to implement untied task without user-level thread.
So, implementing user-level thread for tied task will keep simplicity
of task scheduler
since libgomp will have untied task implementation in the future.

> IMHO you don't want to rewrite the task support, just primarily investigate
> various scheduling algorithms and attempt to implement some of them and
> benchmark.

(Continue reading)

Jakub Jelinek | 3 May 10:19 2011
Picon

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
(Continue reading)

Andrew Stubbs | 3 May 11:51 2011

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


Gmane