Hi Tobias!
On 10.02.2014 03:10, Tobias Burnus wrote:
Shouldn't you also reject polymorphic types ("BT_CLASS" and
"BT_ASSUMED")? [BT_CLASS = "class(derived_type_name)" or "class(*)";
BT_ASSUMED = "type(*)"]
+ if (n->sym->attr.pointer)
+gfc_error ("POINTER object '%s' in %s clause
Hi!
On Mon, 10 Feb 2014 00:10:26 +0100, Tobias Burnus wrote:
> Ilmir Usmanov wrote:
> > OpenACC 1.0 fortran FE support -- matching and resolving.
> > +static void
> > +resolve_oacc_cache (gfc_code *)
> > +{
> > + //TODO: resolve subarrays
> > +}
>
> ;-)
Just to clarify: I'm fine with inc
Ilmir Usmanov wrote:
OpenACC 1.0 fortran FE support -- matching and resolving.
+ return MATCH_ERROR;
+}
+
+static match
+match_oacc_clause_gang (gfc_omp_clauses *cp)
+{
For consistency, can you add another empty line before the function?
+#define OMP_CLAUSE_SEQ (1ll
OpenACC 1.0 fortran FE support -- matching and resolving.
* openmp.c (gfc_free_omp_clauses): Remove also OpenACC clauses.
(gfc_free_exprlist): New function to clear expression list.
(match_oacc_exprlist): New function to match expression list.
(match_oacc_clause_gang): New fun
Hi!
Regarding my comments, please keep in mind that I don't have a lot of
Fortran experience; neither as a user nor as an implementor ;-) in the
GCC front end, so don't hesitate to tell me if I'm misunderstanding
something. As I suggested, it may make sense to CC Fortran front end
maintainers for
