setcontext et al. functions (was: Inquiry about GCC Summer Of Code project idea.)

[Thomas Schwinge]

Hi!

On Wed, 15 May 2013 16:04:02 +0200, I wrote:
> As for the roadblock:
> 
> > On Tue, Apr 30, 2013 at 4:58 PM, Ian Lance Taylor  wrote:
> > 
> > > 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.
> 
> I think I have found a way so that we can hack around that problem on the
> Hurd/glibc side (that is, implement the setcontext et al. function in the
> threadvars environment) until we're able to address the issue properly
> (replace threadvars with TLS proper).  Not yet implemented and tested,
> but I'm on it; slowly, time is limited.

In fact, I implemented and (lightly) tested that three weeks ago,
.
Cleanup remaining to be done, if someone is interested: fix documentation
bug in sysdeps/mach/hurd/i386/makecontext-helper.c (as a void function,
makecontext can't actually return an error, deferring checking until
setcontext/swapcontext would be clumsy, and their callers would very
likely not be prepared to handle and recover from EINVAL or something),
copy sysdeps/mach/hurd/i386/makecontext-helper.c into a libpthread sysdep
directory, remove libpthread bits from
sysdeps/mach/hurd/i386/makecontext-helper.c (or instead adjust for C
threads, but probably not worth it).  Anyway, Samuel, would you please
put the current »tg patch t/context_functions« as a new patch into the
Debian glibc package?


Grüße,
 Thomas


pgp9cz_WQ9D_I.pgp
Description: PGP signature

Re: Memory dependence

[Richard Biener]

On Tue, Jun 11, 2013 at 7:07 AM, shmeel gutl
 wrote:
> In the architecture that I am using, there is a big pipeline penalty for
> read after write to the same memory location. Is it possible to tell the
> difference between a possible memory conflict and a definite memory
> conflict?

Not with existing API on the RTL level.  But the RTL dependence checking
code has "must" and "may" pieces that could be factored out.

Richard.

Hurd port for GCC Go (was: [PATCH] gccgo patch 0-2 (9))

[Thomas Schwinge]

Hi!

On Fri, 07 Jun 2013 11:14:31 +0200, Svante Signell  
wrote:
> Attached are patches to enable gccgo to build properly on Debian
> GNU/Hurd on gcc-4.7 (4.7.3-4).

Thanks!  I've begun integrating them into my GCC tree (based on upstream
GCC trunk, so some changes to be done to your patches), and get it in a
state for Fotis to base his GSoC work on.


Grüße,
 Thomas


pgppcer9GgoKJ.pgp
Description: PGP signature

Custom hash tables in extensions

[Alex Leach]

Dear GCC devs,

I hope you don't mind me posting on this list. I'm trying to finish up an  
AST to XML converter, which I started porting from GCC-XML (a patched  
version of GCC-4.2) to a GCC plugin, quite a while ago now.


I'd really appreciate any help with finishing this up, as there's a lot to  
learn about GCC's internal garbage collection mechanisms, and I can't  
afford to burn much time on this at the moment, but I would like it to  
actually work...



(Please excuse the use of `VEC(tree, gc)` instead of `vec` in  
this email; I'm accommodating for both in my code. Also, sorry about the  
length of this; I'm not very good at concise...)



Current plugin deficiency, cf. original GCCXML implementation
-

One of the (last?) limitations of the plugin as it stands, is that each  
`cp_binding_level` is missing an extra `VEC(tree, gc)*` member, which was  
originally patched in to name-lookup.h. This VEC - i.e.  
`cp_binding_level->all_decls` - stored all (grand-)child declarations  
passed by `ht_forall(ident_hash, callback, 0);` to `callback`, just before  
the XML dump starts. (`callback` is implemented as  
`xml_fill_all_decls`[1]).


I've tried generating this `all_decls` vector on the fly, during the main  
dump routine, but it seems that the information needs to be gathered in a  
separate, preliminary pass of the AST, which is what the `ht_forall` call  
achieves. Each `cp_binding_level`'s `all_decls` member is populated by  
recursing backwards through each `cxx_binding`'s `previous` member, while  
`ht_forall` recurses forward through the AST.


The full `all_decls` member is used during the XML dump, only when writing  
out complete `NAMESPACE_DECL`s. (see lines preceding 1673, of  
`xml_output_namespace_decl`[2]).



Custom hash table


I've been browsing the GCC code and reading the internals manual, and it  
seems to me that one way to replicate this functionality in a plugin,  
would be to use `ht_forall(ident_hash, ..)` to populate a separate hash  
table, mapping IDENTIFIER_NODE's to VEC's.


I'm sure you're all aware that implementing that, is much easier said than  
done! I had a grep for GCC source code using `ht_` functions, and came  
across stringpool.c. So I started modifying code from there, and then came  
to a bit of a wall: `struct GTY(()) string_pool_data`.


If I understand stringpool.c correctly, one `string_pool_data` instance is  
assigned to each `hashnode`, but I don't know how to get  
`string_pool_data` out of its hashnode.. Is there some gengtype-generated  
function that achieves this, or is a cast all that's required?


If this is the way to go about getting that `all_decls` VEC, please could  
someone help me out(!), or point me at some source code that has a GTY'd  
mapping of IDENTIFIER_NODE's to VEC's? I've got chapter 22 of the  
Internals manual in front of me (Memory Management and Type Information),  
but it's a lot to take in. It also looks like I'll have to figure out  
chapter 22.4, on how to use the `PLUGIN_GGC_(START|END)` callbacks, which  
will also take some time.. Pointers to any existing examples where this is  
done, would be really appreciated!



Using the existing hash table, `ident_hash`


This would be ideal. I think it would be the least amount of code,  
wouldn't require gengtype, or the call to `ht_forall`. If this is possible  
(I'm sure it is), I've failed to get a working implementation. At first I  
changed `xml_fill_all_decls`, to instead put the VEC of declarations into  
each `cxx_binding`s `static_decls`. This gives improper results, however,  
I think due to duplicating declarations and messing with things I  
shouldn't touch.


My second attempt got rid of the `ht_forall` call, and instead used  
`ht_lookup(ident_hash, ...)` during the dump, to get a namespace's  
hashnode. But I haven't got this to work, because I haven't found a way to  
get a VEC of all declarations, recursively, given the namespace node (as  
either a `tree`, `hashnode` or `cxx_binding`). One inefficiency of doing  
it this way, is that each time a nested namespace is encountered, then it  
would have to repeat itself, as the parent namespace had already recursed  
through it when populating its own VEC. Potential benefit: reduced minimum  
memory usage during the dump. Still, I can't figure out which are the  
necessary API functions or macros. I get lost looking in the tree.h files..


Either way, the method doesn't matter so much, as long as the result is  
accurate and the implementation saves some time.



Ways to help..


If you're familiar with the GTY datatypes, gengtype, hash tables and / or  
`tree.h`, please could you help me decide how I can replace the  
`cp_binding_level->all_decls` member, and also with finding usage examples  
of the relevant internal GCC API(s). If you'd be happy to contribute code,  
that would be even better! All due credit will be given where deserved, of  
course.



Current code
---

If you'd lik

Re: lower-subreg and IBM long double

[Joseph S. Myers]

On Tue, 11 Jun 2013, Alan Modra wrote:

> Index: gcc/doc/tm.texi.in
> ===
> --- gcc/doc/tm.texi.in(revision 199781)
> +++ gcc/doc/tm.texi.in(working copy)
> @@ -6375,6 +6375,12 @@
>  registers on machines with lots of registers.
>  @end deftypefn
>  
> +@hook TARGET_INIT_LOWER_SUBREG
> +This hook allows modification of the choices the lower_subreg pass
> +will make for particular subreg modes.  @var{data} is a pointer to a
> +@code{struct target_lower_subreg}.
> +@end deftypefn

It's preferred to put the hook documentation in the doc string in 
target.def, so tm.texi.in then only contains the @hook line indicating 
where the documentation will go in tm.texi.

-- 
Joseph S. Myers
jos...@codesourcery.com