This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/50690] [4.7 Regression] ICE with front end optimization and OMP workshare
- From: "burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 11 Oct 2011 18:34:01 +0000
- Subject: [Bug fortran/50690] [4.7 Regression] ICE with front end optimization and OMP workshare
- Auto-submitted: auto-generated
- References: <bug-50690-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50690
--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-10-11 18:34:01 UTC ---
(In reply to comment #1)
> To me, the right strategy appears to be to mark the temporary
> variable as threadprivate if we are within an OMP block.
To me it sounds like the right solution to the wrong problem. The issue is that
WORKSHARE does not expect an EXPR_BLOCK. I think as long as there are only
work-share allowed items in EXPR_BLOCK, one can continue to translate the
OpenMP workshare as it - handling EXPR_BLOCK explicitly.
Independent of that, one should check whether one has to put the temporary in
thread-private memory. However, that applies then to all FE-optimization
temporaries as one never knows whether on is in a parallel block or not. It
might also affect other temporaries, gfortran generates. (Still, I was/am under
the impression that it is not needed in that case to mark such variable as
being thread local as they are just put on the stack. That's different for
static/external variables.)