Re: [gsoc2015] Is Gimple FE eligible for gsoc this year?
On March 19, 2015 4:57:37 AM GMT+01:00, Trevor Saunders wrote: >On Wed, Mar 18, 2015 at 11:09:28PM +0800, xue yinsong wrote: >> >> >> >> >> >> On 15/3/18 下午10:08, "Diego Novillo" wrote: >> >> >On Wed, Mar 18, 2015 at 2:54 AM, xue yinsong > wrote: >> > >> >> Somehow this project is not in the gsoc ideas list, and it’s been >one year since the last commit(According to >https://gcc.gnu.org/svn/gcc/branches/gimple-front-end/ChangeLog). >> >> >> >> Could someone tell me if this project is still active and eligible >for this year’s gsoc? >> > >> >I'm not sure. You'd have to find someone willing to mentor. There >are >> >other cleanups necessary for this to be viable. Perhaps start with >> >those? >> > >> > >> >Diego. >> >> I’m glad to get started now. >> Could you please give me some specific directions to work on ? > >I can't realistically offer more than to be a back up mentor for this >given my level of experience and available time. That said here are my >thoughts on how to proceed on this project. The first big use for the >gimple front end will be to be able to test specific bits of the >compiler with less interference from other parts. If you can merge >something that will let some people write tests for their bugs / >features with less work then the natural tendancy will be to improve >the >gimple front end. So I think the first goal should be to merge >something that works in some cases and then work on fixing the cases it >can't be used in. So first merge trunk into the gimple-front-end >branch. Then get the gimple front end to create gimple and pass it >down >to the optimizer. Once that works I suspect you will be able to write >test cases for some bugs people are fixing for the gimple front end to >prove it can test things easily. If you get to that point I think we >should look at merging the branch into main line and we can talk about >next steps. I agree. I'd be willing to mentor this. Richard. >thanks and good luck! > >Trev > >> >> >> Yinsong. >>
Re: [debug-early] emitting early debug for external variables
On Wed, Mar 18, 2015 at 10:28 PM, Jason Merrill wrote: > If you move the call to rest_of_decl_compilation we could go through and > prune the debug info for unused decls at dwarf2out_finish time, the way we > do with unused types. True. Note that the varpool nodes eventually get created once the first use is seen. So I wonder how much garbage we create by unconditionally creating the node in rest_of_decl_compilation (yeah, header files, of course - probably a similar issue for unused function declarations?). I'd prefer to do early_global_decl from rest_of_decl_compilation (and shun the symtab/varpool walk - but that would require the FEs would hand off each global that possibly needs debug info through rest_of_decl_compilation). To prune globals during early(!) dwarf2out_finish you should be able to use the symbol table (not sure if we prune all unused symbols, but surely the list of references should be empty). Richard. > Jason
Re: [gomp4] Questions about "declare target" and "target update" pragmas
On Mon, Mar 16, 2015 at 09:41:53PM +0300, Ilya Verbin wrote:
> On Tue, Mar 10, 2015 at 19:52:52 +0300, Ilya Verbin wrote:
> > Hi Jakub,
> >
> > I have one more question :)
> > This testcase seems to be correct... or not?
> >
> > #pragma omp declare target
> > extern int G;
> > #pragma omp end declare target
> >
> > int G;
> >
> > int main ()
> > {
> > #pragma omp target update to(G)
> >
> > return 0;
> > }
> >
> > If yes, then we have a problem that the decl of G in
> > varpool_node::get_create
> > doesn't have "omp declare target" attribute.
>
> Ping?
Here is untested patch. I'm going to check it in after bootstrap/regtest.
> I am investigating run-fails on some benchmark, and have found a second
> questionable place, where a function argument overrides a global array.
> Just to be sure, is this a bug in the test?
>
> #pragma omp declare target
> int a1[50], a2[50];
> #pragma omp end declare target
>
> void foo (int a1[])
> {
> #pragma omp target
> {
> a1[10]++;
> a2[10]++;
> }
> }
That is a buggy test. int a1[] function argument is changed
into int *a1, so it is actually
#pragma omp target map(tofrom:a1, a2)
{
a1[10]++;
a2[10]++;
}
which copies the a1 pointer to the device by value (no pointer
transformation).
Perhaps the testcase writer meant to use #pragma omp target map(a1[10])
instead (or map(a1[0:50])?
2015-03-19 Jakub Jelinek
* c-decl.c (c_decl_attributes): Also add "omp declare target"
attribute for DECL_EXTERNAL VAR_DECLs.
* decl2.c (cplus_decl_attributes): Also add "omp declare target"
attribute for DECL_EXTERNAL VAR_DECLs.
* testsuite/libgomp.c/target-10.c: New test.
* testsuite/libgomp.c++/target-4.C: New test.
--- gcc/c/c-decl.c.jj 2015-03-09 19:24:34.0 +0100
+++ gcc/c/c-decl.c 2015-03-19 13:01:15.423381262 +0100
@@ -4407,7 +4407,8 @@ c_decl_attributes (tree *node, tree attr
{
/* Add implicit "omp declare target" attribute if requested. */
if (current_omp_declare_target_attribute
- && ((TREE_CODE (*node) == VAR_DECL && TREE_STATIC (*node))
+ && ((TREE_CODE (*node) == VAR_DECL
+ && (TREE_STATIC (*node) || DECL_EXTERNAL (*node)))
|| TREE_CODE (*node) == FUNCTION_DECL))
{
if (TREE_CODE (*node) == VAR_DECL
--- gcc/cp/decl2.c.jj 2015-03-18 11:53:13.0 +0100
+++ gcc/cp/decl2.c 2015-03-19 13:04:30.739176009 +0100
@@ -1440,7 +1440,8 @@ cplus_decl_attributes (tree *decl, tree
/* Add implicit "omp declare target" attribute if requested. */
if (scope_chain->omp_declare_target_attribute
- && ((TREE_CODE (*decl) == VAR_DECL && TREE_STATIC (*decl))
+ && ((TREE_CODE (*decl) == VAR_DECL
+ && (TREE_STATIC (*decl) || DECL_EXTERNAL (*decl)))
|| TREE_CODE (*decl) == FUNCTION_DECL))
{
if (TREE_CODE (*decl) == VAR_DECL
--- libgomp/testsuite/libgomp.c/target-10.c.jj 2015-03-19 13:06:56.812778618
+0100
+++ libgomp/testsuite/libgomp.c/target-10.c 2015-03-19 13:07:03.857662996
+0100
@@ -0,0 +1,14 @@
+/* { dg-do run } */
+
+#pragma omp declare target
+extern int v;
+#pragma omp end declare target
+
+int v;
+
+int
+main ()
+{
+ #pragma omp target update to(v)
+ return 0;
+}
--- libgomp/testsuite/libgomp.c++/target-4.C.jj 2015-03-19 13:07:19.286409775
+0100
+++ libgomp/testsuite/libgomp.c++/target-4.C2015-03-19 13:07:30.38651
+0100
@@ -0,0 +1,3 @@
+// { dg-do run }
+
+#include "../libgomp.c/target-10.c"
Jakub
Re: [gomp4] Questions about "declare target" and "target update" pragmas
On Thu, Mar 19, 2015 at 14:47:44 +0100, Jakub Jelinek wrote:
> Here is untested patch. I'm going to check it in after bootstrap/regtest.
Thanks.
> > I am investigating run-fails on some benchmark, and have found a second
> > questionable place, where a function argument overrides a global array.
> > Just to be sure, is this a bug in the test?
> >
> > #pragma omp declare target
> > int a1[50], a2[50];
> > #pragma omp end declare target
> >
> > void foo (int a1[])
> > {
> > #pragma omp target
> > {
> > a1[10]++;
> > a2[10]++;
> > }
> > }
>
> That is a buggy test. int a1[] function argument is changed
> into int *a1, so it is actually
> #pragma omp target map(tofrom:a1, a2)
Actually, it copies only a1 pointer, since a2 points to the global array.
> {
> a1[10]++;
> a2[10]++;
> }
> which copies the a1 pointer to the device by value (no pointer
> transformation).
> Perhaps the testcase writer meant to use #pragma omp target map(a1[10])
> instead (or map(a1[0:50])?
If I understand correctly, it's not allowed to map global target arrays this
way, since it's already present in the initial device data environment:
2.9.4 declare target Directive
If a list item is a variable then the original variable is mapped to a
corresponding
variable in the initial device data environment for all devices.
2.14.5 map Clause
If a corresponding list item of the original list item is in the enclosing
device data
environment, the new device data environment uses the corresponding list item
from the
enclosing device data environment. No additional storage is allocated in the
new device
data environment and neither initialization nor assignment is performed,
regardless of
the map-type that is specified.
So, to fix this testcase I can just remove the "int a1[]" function argument, and
add some "#pragma omp target update" where needed.
-- Ilya
Re: [gomp4] Questions about "declare target" and "target update" pragmas
On Thu, Mar 19, 2015 at 05:49:47PM +0300, Ilya Verbin wrote:
> > > void foo (int a1[])
> > > {
> > > #pragma omp target
> > > {
> > > a1[10]++;
> > > a2[10]++;
> > > }
> > > }
> >
> > That is a buggy test. int a1[] function argument is changed
> > into int *a1, so it is actually
> > #pragma omp target map(tofrom:a1, a2)
>
> Actually, it copies only a1 pointer, since a2 points to the global array.
Sure, the implicit map(tofrom:a2) doesn't really do anything, since a2
is clearly already mapped and will stay to be mapped, and is a global var.
>
> > {
> > a1[10]++;
> > a2[10]++;
> > }
> > which copies the a1 pointer to the device by value (no pointer
> > transformation).
> > Perhaps the testcase writer meant to use #pragma omp target map(a1[10])
> > instead (or map(a1[0:50])?
>
> If I understand correctly, it's not allowed to map global target arrays this
> way, since it's already present in the initial device data environment:
It of course is allowed. It just means that it doesn't allocate new memory
(sizeof(int) large in the map(a1[10]) case, sizeof(int)*50 large in the
map(a1[0:50])
case), nor copy the bytes around, all it will do is allocate memory for the
target copy of the a1 pointer, and do pointer transformation such that the
a1 pointer on the target will point to the global target a1 array.
Without the map(a1[10]) or map(a1[0:50]) clauses (i.e. implicit map(tofrom:a1))
it does similar thing, except it copies the pointer value to the target (and
back at the end of the region) instead, which is not what you want...
> So, to fix this testcase I can just remove the "int a1[]" function argument,
> and
> add some "#pragma omp target update" where needed.
Well, supposedly the test was meant to test it with a pointer parameter,
otherwise why would there be both a1 and a2 when a2 would be enough?
Jakub
Re: [gsoc2015] Is Gimple FE eligible for gsoc this year?
On Thu, Mar 19, 2015 at 08:36:50PM +0800, xue yinsong wrote: > Thanks for the guidance. > > I tried to merge thunk into this branch. > However, it seems a small part of Gimple FE is a bit outdated. > > > is_param / is_marked / htab are still used in parser.c > ( https://gcc.gnu.org/svn/gcc/branches/gimple-front-end/gcc/gimple/parser.c ). yeah, you can look at my patches to remove that stuff from trunk for guidance on how to fix that up. > It may take me some time to fix these. that's expected given the branch hasn't merged with trunk in a long time, and I kind of suspect it didn't actually work at the last merge I did. Trev > > Yinsong > > On 15/3/19 上午11:57, "Trevor Saunders" wrote: > > >On Wed, Mar 18, 2015 at 11:09:28PM +0800, xue yinsong wrote: > >> > >> > >> > >> > >> > >> On 15/3/18 下午10:08, "Diego Novillo" wrote: > >> > >> >On Wed, Mar 18, 2015 at 2:54 AM, xue yinsong > >> >wrote: > >> > > >> >> Somehow this project is not in the gsoc ideas list, and it’s been one > >> >> year since the last commit(According to > >> >> https://gcc.gnu.org/svn/gcc/branches/gimple-front-end/ChangeLog). > >> >> > >> >> Could someone tell me if this project is still active and eligible for > >> >> this year’s gsoc? > >> > > >> >I'm not sure. You'd have to find someone willing to mentor. There are > >> >other cleanups necessary for this to be viable. Perhaps start with > >> >those? > >> > > >> > > >> >Diego. > >> > >> I’m glad to get started now. > >> Could you please give me some specific directions to work on ? > > > >I can't realistically offer more than to be a back up mentor for this > >given my level of experience and available time. That said here are my > >thoughts on how to proceed on this project. The first big use for the > >gimple front end will be to be able to test specific bits of the > >compiler with less interference from other parts. If you can merge > >something that will let some people write tests for their bugs / > >features with less work then the natural tendancy will be to improve the > >gimple front end. So I think the first goal should be to merge > >something that works in some cases and then work on fixing the cases it > >can't be used in. So first merge trunk into the gimple-front-end > >branch. Then get the gimple front end to create gimple and pass it down > >to the optimizer. Once that works I suspect you will be able to write > >test cases for some bugs people are fixing for the gimple front end to > >prove it can test things easily. If you get to that point I think we > >should look at merging the branch into main line and we can talk about > >next steps. > > > >thanks and good luck! > > > >Trev > > > >> > >> > >> Yinsong. > >> >
Re: [gomp4] Questions about "declare target" and "target update" pragmas
On Thu, Mar 19, 2015 at 15:57:10 +0100, Jakub Jelinek wrote: > On Thu, Mar 19, 2015 at 05:49:47PM +0300, Ilya Verbin wrote: > > If I understand correctly, it's not allowed to map global target arrays this > > way, since it's already present in the initial device data environment: > > It of course is allowed. It just means that it doesn't allocate new memory > (sizeof(int) large in the map(a1[10]) case, sizeof(int)*50 large in the > map(a1[0:50]) > case), nor copy the bytes around, all it will do is allocate memory for the > target copy of the a1 pointer, and do pointer transformation such that the > a1 pointer on the target will point to the global target a1 array. > Without the map(a1[10]) or map(a1[0:50]) clauses (i.e. implicit > map(tofrom:a1)) > it does similar thing, except it copies the pointer value to the target (and > back at the end of the region) instead, which is not what you want... Ok, got it. And what about global allocatable fortran arrays? I didn't find any restrictions in the specification. Here is a reduced testcase: module test integer, allocatable, target :: x(:) !$omp declare target(x) end module test use test integer :: n = 1000 allocate (x(n)) !$omp target map(x(1:n)) x(123) = 456 !$omp end target deallocate (x) end It crashes on target with NULL-pointer access, however the memory for x(1:n) is allocated on target. Looks like there's something wrong with pointer transformation. Is this a wrong testcase or a bug in gcc? Thanks, -- Ilya
Re: [gomp4] Questions about "declare target" and "target update" pragmas
On Thu, Mar 19, 2015 at 09:42:58PM +0300, Ilya Verbin wrote: > Ok, got it. > > And what about global allocatable fortran arrays? I didn't find any > restrictions in the specification. Here is a reduced testcase: This really can't be supported. If you have global allocatables, you really should allocate them in the target IMNSHO. The allocation on the host doesn't make it allocated on the target. Otherwise, how you could e.g. deallocate it on the target or allocate again? > > module test > integer, allocatable, target :: x(:) > !$omp declare target(x) > end module test > use test > integer :: n = 1000 > allocate (x(n)) > !$omp target map(x(1:n)) > x(123) = 456 > !$omp end target > deallocate (x) > end > > It crashes on target with NULL-pointer access, however the memory for x(1:n) > is > allocated on target. Looks like there's something wrong with pointer > transformation. Is this a wrong testcase or a bug in gcc? Jakub
gcc-4.8-20150319 is now available
Snapshot gcc-4.8-20150319 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20150319/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 221523 You'll find: gcc-4.8-20150319.tar.bz2 Complete GCC MD5=d0ef86e14b3c01cb2363402ceb54c050 SHA1=021bcaced3178dad9deb62bfe2a23e216b90991d Diffs from 4.8-20150312 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 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.
