[Bug c/26751] New: Some OpenMP semantics are caught too late

[Bug c/26751] New: Some OpenMP semantics are caught too late

[pinskia at gcc dot gnu dot org]

switch (default_kind)
        {
        case OMP_CLAUSE_DEFAULT_NONE:
          error ("%qs not specified in enclosing parallel",
                 IDENTIFIER_POINTER (DECL_NAME (decl)));
          error ("%Henclosing parallel", &ctx->location);

......
  n = splay_tree_lookup (ctx->variables, (splay_tree_key)decl);
  if (n != NULL)
    {
      if (n->value & GOVD_SHARED)
        {
          if (ctx == gimplify_omp_ctxp)
            error ("iteration variable %qs should be private",
                   IDENTIFIER_POINTER (DECL_NAME (decl)));
          n->value = GOVD_PRIVATE;
        }
      return true;
    }



--------
The gimplifier should not be emitting errors.


-- 
           Summary: Some OpenMP semantics are caught too late
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Keywords: openmp
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org
OtherBugsDependingO 24222
             nThis:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26751

[Bug c/26751] [4.2 Regression] Some OpenMP semantics are caught too late (in the gimplifier)

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rth at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-04-12 22:41:46
               date|                            |
            Summary|Some OpenMP semantics are   |[4.2 Regression] Some OpenMP
                   |caught too late (in the     |semantics are caught too
                   |gimplifier)                 |late (in the gimplifier)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26751

[Bug c/26751] [4.2 Regression] Some OpenMP semantics are caught too late (in the gimplifier)

[dnovillo at gcc dot gnu dot org]

------- Comment #1 from dnovillo at gcc dot gnu dot org  2006-04-28 19:02 -------
(In reply to comment #0)

> The gimplifier should not be emitting errors.
> 
Why, exactly?  Some diagnostics are impossible to emit early enough.  Is this a
documented requirement?  What's the rationale?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26751

[Bug c/26751] [4.2 Regression] Some OpenMP semantics are caught too late (in the gimplifier)

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-04-28 19:05 -------
(In reply to comment #1) 
> Why, exactly?  Some diagnostics are impossible to emit early enough.  Is this a
> documented requirement?  What's the rationale?

Read the comments in PR 24222 but basicially the gimplifier is not should not
being doing any semantic anlyasis, that is the job of the front-end.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26751

[Bug c/26751] [4.2 Regression] Some OpenMP semantics are caught too late (in the gimplifier)

[dnovillo at gcc dot gnu dot org]

------- Comment #3 from dnovillo at gcc dot gnu dot org  2006-04-28 19:17 -------
(In reply to comment #2)

> Read the comments in PR 24222 but basicially the gimplifier is not should not
> being doing any semantic anlyasis, that is the job of the front-end.
> 
Well, some of the structural analysis for which emit errors is done even later
than that, so it would be naive to pretend that we can catch everything during
parsing.

If you find a non-intrusive way of bubbling this diagnostic up to the parser,
be my guest.  Otherwise, we should close as WONTFIX.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26751

Re: [Bug c/26751] [4.2 Regression] Some OpenMP semantics are caught too late (in the gimplifier)

[Andrew Pinski]

> 
> 
> 
> ------- Comment #3 from dnovillo at gcc dot gnu dot org  2006-04-28 19:17 -------
> Well, some of the structural analysis for which emit errors is done even later
> than that, so it would be naive to pretend that we can catch everything during
> parsing.

I don't understand why it is hard.  

> 
> If you find a non-intrusive way of bubbling this diagnostic up to the parser,
> be my guest.  Otherwise, we should close as WONTFIX.

GDR will become upset with you if you close as WILL NOT FIX.

Also I did not mark this as a regression on purpose so we can keep track
of the problems with reporting errors late in the game.

Really after the front-end is done parsing, calling error should be turned
into an internal error.

-- Pinski

[Bug c/26751] [4.2 Regression] Some OpenMP semantics are caught too late (in the gimplifier)

[pinskia at physics dot uc dot edu]

------- Comment #4 from pinskia at physics dot uc dot edu  2006-04-28 19:20 -------
Subject: Re:  [4.2 Regression] Some OpenMP semantics are caught too late (in
the gimplifier)

> 
> 
> 
> ------- Comment #3 from dnovillo at gcc dot gnu dot org  2006-04-28 19:17 -------
> Well, some of the structural analysis for which emit errors is done even later
> than that, so it would be naive to pretend that we can catch everything during
> parsing.

I don't understand why it is hard.  

> 
> If you find a non-intrusive way of bubbling this diagnostic up to the parser,
> be my guest.  Otherwise, we should close as WONTFIX.

GDR will become upset with you if you close as WILL NOT FIX.

Also I did not mark this as a regression on purpose so we can keep track
of the problems with reporting errors late in the game.

Really after the front-end is done parsing, calling error should be turned
into an internal error.

-- Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26751

[Bug c/26751] [4.2 Regression] Some OpenMP semantics are caught too late (in the gimplifier)

[rth at gcc dot gnu dot org]

------- Comment #5 from rth at gcc dot gnu dot org  2006-05-01 15:11 -------
We went through three iterations of this on the branch.

The variable identification step cannot be done before gimplification,
because it requires that we also mark some variables that are created
by the gimplification process.

The step is complex enough that writing three different versions of the
pass to generate error messages from the front end proved to be intractable.

I, for one, am not going to change this.


-- 

rth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26751