[Bug tree-optimization/66846] New: parloops does not always mark loops for fixup if needed

[Bug tree-optimization/66846] New: parloops does not always mark loops for fixup if needed

[vries at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6968 bytes --]

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

            Bug ID: 66846
           Summary: parloops does not always mark loops for fixup if
                    needed
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

In openmp expansion of loops, we do some effort to try to create matching loops
in the loop state of the child function, and if that doesn't work out, to mark
the loop state for fixup.

This checking code checks that we actually do one or the other:
...
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 0e69bc2..1b64298 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -5603,6 +5603,12 @@ expand_omp_taskreg (struct omp_region *region)
        }
       if (gimple_in_ssa_p (cfun))
        update_ssa (TODO_update_ssa);
+      if (!loops_state_satisfies_p (LOOPS_NEED_FIXUP))
+       {
+#ifdef ENABLE_CHECKING
+         verify_loop_structure ();
+#endif
+       }
       pop_cfun ();
     }

...

With this checking code enabled, we run into errors here:
...
src/gcc/testsuite/gcc.dg/autopar/outer-1.c: In function ‘parloop._loopfn.0’:
src/gcc/testsuite/gcc.dg/autopar/outer-1.c:11:3: error: loop with header 5 not
in loop tree
src/gcc/testsuite/gcc.dg/autopar/outer-1.c:11:3: internal compiler error: in
verify_loop_structure, at cfgloop.c:1647
0x884d18 verify_loop_structure()
        src/gcc/cfgloop.c:1647
0xe1d746 expand_omp_taskreg
        src/gcc/omp-low.c:5609
0xe2d904 expand_omp
        src/gcc/omp-low.c:9301
0xe2de07 execute_expand_omp
        src/gcc/omp-low.c:9498
0xe2df54 execute
        src/gcc/omp-low.c:9583
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
...

In outer-1.c, we parallelize an outer loop. In the parloops pass, we cancel
both the outer and inner loop in the loop state:
...
  /* Cancel the loop (it is simpler to do it here rather than to teach the
     expander to do it).  */
  cancel_loop_tree (loop);

...

During omp-expand, we only create a loop in the loop state for the new outer
loop, but not the inner loop. Hence the ICE.

Normally, we don't run into trouble because we set the loop state for fixup
anyway in execute_fixup_cfg in pass_fixup_cfg:
...
8804      if (current_loops
8805          && (todo & TODO_cleanup_cfg))
8806        loops_state_set (LOOPS_NEED_FIXUP);
...

The todo contains TODO_cleanup_cfg, because of this code, in the
'gimple_in_ssa_p (cfun)' branch:
...
          if (decl)
            {
              int flags = gimple_call_flags (stmt);
              if (flags & (ECF_CONST | ECF_PURE | ECF_LOOPING_CONST_OR_PURE))
                {
                  if (gimple_purge_dead_abnormal_call_edges (bb))
                    todo |= TODO_cleanup_cfg;

                  if (gimple_in_ssa_p (cfun))
                    {
                      todo |= TODO_update_ssa | TODO_cleanup_cfg;
                      update_stmt (stmt);
                    }
                }
...

The code is triggered for stmt:
...
_7 = __builtin_omp_get_num_threads ();
...
which has flags ECF_CONST.
>From gcc-bugs-return-492070-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 12 13:38:46 2015
Return-Path: <gcc-bugs-return-492070-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 97434 invoked by alias); 12 Jul 2015 13:38:46 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 97403 invoked by uid 48); 12 Jul 2015 13:38:42 -0000
From: "db0451 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66847] New: Derived class calling protected base ctor using C++11 {brace} init = spurious access denied error
Date: Sun, 12 Jul 2015 13:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: db0451 at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created
Message-ID: <bug-66847-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg00960.txt.bz2
Content-length: 1625

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf847

            Bug ID: 66847
           Summary: Derived class calling protected base ctor using C++11
                    {brace} init = spurious access denied error
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: db0451 at gmail dot com
  Target Milestone: ---

Created attachment 35953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id5953&actioníit
source file

Possible duplicate of 63151. Probably related to the still-outstanding 66617
and references therein.

G++ continues to have severe problems implementing the new {brace}
initialisation syntax.

The two problems I've observed so far seem to be instigated by use of virtual
inheritance elsewhere in the class hierarchy, though I am not certain whether
that is an essential component of the problem.

Attaching cpp and processed output demonstrating that:
- when {brace} call to protected parent ctor is used, G++ errors out and does
not allow compilation.
- Yet replacing that call with (parenthesis) syntax results in the proper
behaviour.

Similar to my previous ticket, maybe the same root cause.

Please advise when we can expect this to be fixed. It is a basic element of a
4-year-old standard. Users should not be discouraged from adopting relatively
up-to-date practices for fear that otherwise 'gold standard' compilers will not
be able to handle them. G++ is usually a role model for standards compliance!

Thanks,
D.

[Bug tree-optimization/66846] parloops does not always mark loops for fixup if needed

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 35970
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35970&action=edit
Tentative patch

[Bug tree-optimization/66846] parloops does not always mark loops for fixup if needed

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch

--- Comment #2 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01328.html

[Bug tree-optimization/66846] parloops does not always mark loops for fixup if needed

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
updated patch: https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02032.html

[Bug tree-optimization/66846] parloops does not always mark loops for fixup if needed

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
updated patch: https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02451.html

[Bug tree-optimization/66846] parloops does not always mark loops for fixup if needed

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
Author: vries
Date: Fri Jul 31 06:26:44 2015
New Revision: 226427

URL: https://gcc.gnu.org/viewcvs?rev=226427&root=gcc&view=rev
Log:
Don't cancel loop tree in parloops

2015-07-31  Tom de Vries  <tom@codesourcery.com>

        PR tree-optimization/66846
        * omp-low.c (expand_omp_taskreg) [ENABLE_CHECKING]: Call
        verify_loop_structure for child_cfun if !LOOPS_NEED_FIXUP.
        (expand_omp_target) [ENABLE_CHECKING]: Same.
        (execute_expand_omp) [ENABLE_CHECKING]: Call verify_loop_structure for
        cfun if !LOOPS_NEED_FIXUP.
        (expand_omp_for_static_nochunk): Handle simple latch bb.  Handle case
        that omp_for already has its own loop struct.
        * tree-parloops.c (create_phi_for_local_result)
        (create_call_for_reduction): Handle simple latch bb.
        (create_parallel_loop): Add simple latch bb to preserve
        LOOPS_HAVE_SIMPLE_LATCHES.  Record new exit.  Handle simple latch bb.
        (gen_parallel_loop): Remove call to cancel_loop_tree.
        (parallelize_loops): Skip loops that are inner loops of parallelized
        loops.
        (pass_parallelize_loops::execute) [ENABLE_CHECKING]: Call
        verify_loop_structure.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/omp-low.c
    trunk/gcc/tree-parloops.c

[Bug tree-optimization/66846] parloops does not always mark loops for fixup if needed

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from vries at gcc dot gnu.org ---
Fixed on trunk, marking resolved-fixed