Re: GSoC openMP task scheduling Advice

[Tobias Burnus]

guray.ozen wrote:

I thought gcc tasks/threads waiting too much on the idle than intel
compiler's threads.


Regarding busy waits, you could try to tune the values of the 
GOMP_SPINCOUNT environment variable. Search for "@node GOMP_SPINCOUNT" 
in 
http://gcc.gnu.org/viewcvs/gcc/branches/gomp-4_0-branch/libgomp/libgomp.texi?view=co&content-type=text%2Fplain 
for details.


If you have enough cores which are available, there shouldn't be a 
problem with idle. (Except with tasks where one could argue that the 
threads should do task stealing instead.)


Tobias,
who leaves the other questions to Jakub

Re: Computation and usage of SSA_NAME_PTR_INFO

[Richard Biener]

On Mon, Apr 29, 2013 at 7:34 PM, Nikhil Patil  wrote:
> Hello,
>
> 1. Which passes of gcc make use of points-to information in
> SSA_NAME_PTR_INFO (or more precisely, pt_solution) in doing
> optimizations?

All passes that query the alias oracle (tree-ssa-alias.h) which is almost
all passes doing optimization of memory accesses.

>
> 2. Also, who computes this points-to information and populates
> pt_solution? Is it ONLY ipa-pta pass?

It is points-to analysis, both the IPA variant and the local variant
(ealias and alias
passes).

> When I accessed pt_solution through a plugin which REPLACES ipa-pta
> pass, I found that the information (in pt_solution) with and without
> ipa-pta pass differs only in terms of flags in pt_solution. Here with
> the examples I could construct, I found that the bitmap 'vars' in
> pt_solution is same for both the cases. Is it always true?

In theory IPA PTA should be able to compute a more precise solution,
thus have different (less) bits set in 'vars'.  There are several testcases
that show this, look for ipa-pta* testcases in gcc/testsuite/

Richard.

> Can someone please help in clarifying these doubts.
>
> Thanks in advance.
>
> --
> Regards,
> Nikhil Patil.

disable-nls breaks build

[Paulo Matos]

Hello,

I just cloned gcc because of an error I was seeing in my port. It seems to me 
that the problem is the --disable-nls option but I haven't research yet why 
this is happening.

If I configure with:
../gcc/configure --prefix=/home/pmatos/work/tmp/install-gcc/ 
--exec-prefix=/home/pmatos/work/tmp/install-gcc/x86_64-rhel5 --disable-nls 
--enable-checking --disable-shared   --enable-lto --enable-languages=c 
--enable-werror-always

and make.
I get after awhile:
../../gcc/gcc/langhooks.c: In function 'void 
lhd_print_error_function(diagnostic_context*, const char*, diagnostic_info*)':
../../gcc/gcc/langhooks.c:457:41: error: unknown conversion type character 'r' 
in format [-Werror=format]
../../gcc/gcc/langhooks.c:457:41: error: format '%d' expects argument of type 
'int', but argument 5 has type 'const char*' [-Werror=format]
../../gcc/gcc/langhooks.c:457:41: error: unknown conversion type character 'R' 
in format [-Werror=format]
../../gcc/gcc/langhooks.c:457:41: error: too many arguments for format 
[-Werror=format-extra-args]
../../gcc/gcc/langhooks.c:462:31: error: unknown conversion type character 'r' 
in format [-Werror=format]
../../gcc/gcc/langhooks.c:462:31: error: format '%d' expects argument of type 
'int', but argument 5 has type 'const char*' [-Werror=format]
../../gcc/gcc/langhooks.c:462:31: error: unknown conversion type character 'R' 
in format [-Werror=format]
../../gcc/gcc/langhooks.c:462:31: error: too many arguments for format 
[-Werror=format-extra-args]

I am unsure about how nls works and what's causing this since pp_printf seems 
to be fine with %r, %R. I guess the important detail is that the string is 
surrounded by _(...).

Any hints on this?

Paulo Matos

Re: Inquiry about GCC Summer Of Code project idea.

[Thomas Schwinge]

Hi!

I'm sorry for the late answer.  Ian, there's a question for you towards
the bottom of the email.

On Mon, 25 Mar 2013 08:22:15 -0700, Ian Lance Taylor  wrote:
> On Mon, Mar 25, 2013 at 7:42 AM, Fotis Koutoulakis
>  wrote:
> >
> > I am writing this email with regard to a potential project idea that's
> > hosted on the GCC wiki about porting the go programming language GCC
> > (gccgo) frontend to the GNU/HURD operating system (information found
> > here-> http://gcc.gnu.org/wiki/SummerOfCode and here->
> > http://www.gnu.org/software/hurd/open_issues/gccgo.html).
> >
> > My specific queries would be:
> >
> > - This particular idea seems to be eligible for this year's Google
> > Summer Of Code. Further research on the GCC wiki shows that this
> > particular idea has never been implemented in the past - or assigned.
> > However, I would like someone else to assert my assumption that this
> > is eligible for this year's GSOC.
> 
> Yes, it is eligible.
> 
> (This is of course no guarantee that this particular project will be
> selected.  It depends on the other proposals we receive.)

As you can see on
, Svante has
been working on this (outside of the GSoC context), but has not yet
published his patches.  (And yet if he did, I'm condfident there'd still
be enough work left for a GSoC project: (continue) porting Go's runtime
library, language/RPC bindings, etc.)

> > - What would be the specific educational and knowledge background that
> > the student who wishes to implement this particular idea should have?
> > I can see mentions of good POSIX API knowledge, go language knowledge
> > and HURD knowledge here, but I would like to know if there would be
> > more requirements regarding this specific project idea that are not
> > immediately obvious.
> 
> I think you're pretty much right.  I think the most important part
> coming in would be a clear understanding of the HURD, its system call
> interface, and its object file format.  You would have to be able to
> dig into the Go library, to understand how implements the system call
> layer.

Yep.  As for understanding of the Hurd, as long as the project doesn't
shift towards the language/RPC bindings, not really too much Hurd
internals should be needed -- use the standard POSIX interface as
exported by glibc.

> > - What would be a skill level estimate for someone wishing to try this
> > project in an attempt to get his feet wet in compiler engineering?
> 
> Unfortunately it's hard for me to judge.  The most important skill
> would be the ability to dig into some large code bases and understand
> how to change them.

Agreed, and as Samuel already followed up, this is not a project that
will require you to know compiler theory proper, or its implementation.


On  I have just
updated/posted a getcontext/makecontext/setcontext/swapcontext usage
analysis.  This might constitute a "road block": the Hurd currently does
not allow for changing the stack of a process/thread.  Implemented a
while before TLS/__thread variables came along, we have a legacy
threadvar mechanism implemented in glibc, which places thread-local
variables (errno, for example) at the bottom of a thread's stack.  Then,
when switching the stack of a thread, glibc can't locate these anymore,
and "bad things" happen.  This threadvar mechanism is scheduled to go
away (we do implement TLS by now), but when working on that I hit "some
issues" and have not yet found the time to continue.

and

have the details.

Now, it seems the GCC Go port is implemented in a way that makes
extensive use of switching stacks.  So until this threadvar issue is
resolved, there is probably no way to really proceed with the GCC Go port
for GNU Hurd -- unless maybe this stack switching could be hacked around
(Ian?), say, by limiting oneself to not using Goroutines and similar
"specials", and having a custom/minimal Go runtime startup.


Grüße,
 Thomas


pgp9Xg657qVwB.pgp
Description: PGP signature

Re: Inquiry about GCC Summer Of Code project idea.

[Ian Lance Taylor]

On Tue, Apr 30, 2013 at 6:53 AM, Thomas Schwinge
 wrote:
>
> On  I have just
> updated/posted a getcontext/makecontext/setcontext/swapcontext usage
> analysis.  This might constitute a "road block": the Hurd currently does
> not allow for changing the stack of a process/thread.  Implemented a
> while before TLS/__thread variables came along, we have a legacy
> threadvar mechanism implemented in glibc, which places thread-local
> variables (errno, for example) at the bottom of a thread's stack.  Then,
> when switching the stack of a thread, glibc can't locate these anymore,
> and "bad things" happen.  This threadvar mechanism is scheduled to go
> away (we do implement TLS by now), but when working on that I hit "some
> issues" and have not yet found the time to continue.
> 
> and
> 
> have the details.
>
> Now, it seems the GCC Go port is implemented in a way that makes
> extensive use of switching stacks.  So until this threadvar issue is
> resolved, there is probably no way to really proceed with the GCC Go port
> for GNU Hurd -- unless maybe this stack switching could be hacked around
> (Ian?), say, by limiting oneself to not using Goroutines and similar
> "specials", and having a custom/minimal Go runtime startup.

Go does require switching stacks.  A port of Go that doesn't support
goroutines would be useless--nothing in the standard library would
work.  It might be possible to use pthread_getspecific and friends
instead of TLS.

Ian

Re: Need a copyright assignment and a copyright disclaimer form

[Maxim Kuvyrkov]

On 25/04/2013, at 8:51 AM, dw wrote:

> I am attempting to submit a patch for the gcc documentation (see 
> http://gcc.gnu.org/ml/gcc-help/2013-04/msg00193.html).  I am told that I need 
> to submit one of these two forms.  Please send me copies so I can select one 
> and submit it.

You need to forward your email to .  It is the FSF, not the GCC 
project, that handles copyright assignment paperwork.

You need to specify your name, the name of your employer, and the name and 
title of the person who will be signing on behalf of the company.  You also 
need to list which FSFprojects (e.g., GCC, Binutils, GDB, glibc -- or just 
blanket ALL) you wish to contribute to.

Usually the FSF copyright office replies within 1-2 days, and feel free to ping 
us back here at gcc@ if FSF legal stalls.

Thank you,

--
Maxim Kuvyrkov
KugelWorks