From: Jakub Jelinek <jakub@redhat.com>
To: fortran@gcc.gnu.org,
Paul Richard Thomas <paul.richard.thomas@gmail.com>,
Jerry DeLisle <jvdelisle@charter.net>,
Tobias Burnus <burnus@net-b.de>
Cc: gcc-patches@gcc.gnu.org
Subject: [RFC] Change order of Fortran BLOCK_VARS (PR fortran/71687, take 2)
Date: Fri, 01 Jul 2016 14:58:00 -0000 [thread overview]
Message-ID: <20160701145811.GV7387@tucnak.redhat.com> (raw)
In-Reply-To: <20160630180654.GR7387@tucnak.redhat.com>
On Thu, Jun 30, 2016 at 08:06:54PM +0200, Jakub Jelinek wrote:
> So, is it intentional that pushdecl / getdecls acts like a LIFO?
> Though, it seems user vars are pushdecled in the reverse order of
> declarations, but gfc_add_decl_to_function is called in the user declared
> order, so perhaps for the following patch we'd also need to
> decl = nreverse (saved_function_decls);
> in gfc_generate_function_code and similarly in gfc_process_block_locals
> decl = nreverse (saved_local_decls);
Here is an updated patch with the above mentioned two calls to nreverse
added.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-07-01 Jakub Jelinek <jakub@redhat.com>
PR fortran/71687
* f95-lang.c (struct binding_level): Add reversed field.
(clear_binding_level): Adjust initializer.
(getdecls): If reversed is clear, set it and nreverse the names
chain before returning it.
(poplevel): Use getdecls.
* trans-decl.c (gfc_generate_function_code, gfc_process_block_locals):
Use nreverse to pushdecl decls in the declaration order.
* gfortran.dg/gomp/pr71687.f90: New test.
--- gcc/fortran/f95-lang.c.jj 2016-06-30 19:38:38.296737997 +0200
+++ gcc/fortran/f95-lang.c 2016-07-01 12:12:24.821306073 +0200
@@ -286,6 +286,9 @@ binding_level {
tree blocks;
/* The binding level containing this one (the enclosing binding level). */
struct binding_level *level_chain;
+ /* True if nreverse has been already called on names; if false, names
+ are ordered from newest declaration to oldest one. */
+ bool reversed;
};
/* The binding level currently in effect. */
@@ -296,7 +299,7 @@ static GTY(()) struct binding_level *cur
static GTY(()) struct binding_level *global_binding_level;
/* Binding level structures are initialized by copying this one. */
-static struct binding_level clear_binding_level = { NULL, NULL, NULL };
+static struct binding_level clear_binding_level = { NULL, NULL, NULL, false };
/* Return true if we are in the global binding level. */
@@ -310,6 +313,11 @@ global_bindings_p (void)
tree
getdecls (void)
{
+ if (!current_binding_level->reversed)
+ {
+ current_binding_level->reversed = true;
+ current_binding_level->names = nreverse (current_binding_level->names);
+ }
return current_binding_level->names;
}
@@ -347,7 +355,7 @@ poplevel (int keep, int functionbody)
binding level that we are about to exit and which is returned by this
routine. */
tree block_node = NULL_TREE;
- tree decl_chain = current_binding_level->names;
+ tree decl_chain = getdecls ();
tree subblock_chain = current_binding_level->blocks;
tree subblock_node;
--- gcc/fortran/trans-decl.c.jj 2016-05-09 10:20:26.000000000 +0200
+++ gcc/fortran/trans-decl.c 2016-07-01 12:25:30.863415372 +0200
@@ -6277,7 +6277,7 @@ gfc_generate_function_code (gfc_namespac
gfc_finish_block (&cleanup));
/* Add all the decls we created during processing. */
- decl = saved_function_decls;
+ decl = nreverse (saved_function_decls);
while (decl)
{
tree next;
@@ -6469,7 +6469,7 @@ gfc_process_block_locals (gfc_namespace*
if (flag_coarray == GFC_FCOARRAY_LIB && has_coarray_vars)
generate_coarray_init (ns);
- decl = saved_local_decls;
+ decl = nreverse (saved_local_decls);
while (decl)
{
tree next;
--- gcc/testsuite/gfortran.dg/gomp/pr71687.f90.jj 2016-07-01 12:12:24.821306073 +0200
+++ gcc/testsuite/gfortran.dg/gomp/pr71687.f90 2016-07-01 12:12:24.821306073 +0200
@@ -0,0 +1,11 @@
+! PR fortran/71687
+! { dg-do compile }
+! { dg-additional-options "-fstack-arrays -O2" }
+
+subroutine s (n, x)
+ integer :: n
+ real :: x(n)
+!$omp parallel
+ x(1:n) = x(n:1:-1)
+!$omp end parallel
+end
Jakub
next prev parent reply other threads:[~2016-07-01 14:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-30 18:07 [RFC] Change order of Fortran BLOCK_VARS (PR fortran/71687) Jakub Jelinek
2016-07-01 14:58 ` Jakub Jelinek [this message]
2016-07-01 17:59 ` [RFC] Change order of Fortran BLOCK_VARS (PR fortran/71687, take 2) Mikael Morin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160701145811.GV7387@tucnak.redhat.com \
--to=jakub@redhat.com \
--cc=burnus@net-b.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jvdelisle@charter.net \
--cc=paul.richard.thomas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).