This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug fortran/83064] DO CONCURRENT inconsistent results


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064

--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 24 Nov 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
> 
> --- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> There should be no duplication except for vars mentioned in the clauses on
> OpenMP constructs (explicit or implicit).  So, vars declared outside of the
> region and referenced inside of the region are either implicitly or explicitly
> shared/privatized/mapped etc. and vars defined inside of the region are just
> moved to the new outlined function.  We move there the whole BLOCK subtree that
> is fully contained within the region and the vars too.

Yes, that's what I'm seeing with OMP but I'm not seeing that with
autopar.  Ah, it looks like autopar identifies the "local" as to be
globalized in eliminate_local_variables_stmt.

So it would need to somehow detect whether a variable "belongs" to
the loop we are parallelizing.  Which means detecting whether a BLOCK
belongs to a loop?  I guess OMP expansion has an easier job here
given it has an IL that is much closer to source form...

Would we want to record sth like a BLOCK for the scope of a 
loop in the loop structure?  We'd also rely on the CLOBBERs
inside to avoid leaking uses/defs.

Of course a "simple" liveness analysis like that done during
RTL expansion is possible as well.  But I fear that it might
not be good enough.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]