From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84075 invoked by alias); 9 Jul 2015 14:34:51 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 84019 invoked by uid 48); 9 Jul 2015 14:34:47 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/66820] [5/6 Regression] internal compiler error: in get_expr_operands, at tree-ssa-operands.c:910 Date: Thu, 09 Jul 2015 14:34:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 5.1.0 X-Bugzilla-Keywords: openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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/msg00782.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66820 --- Comment #6 from Jakub Jelinek --- So, the problem is that the fold_stmt folding added in that revision creates new decls that it doesn't put into the current gimplification context vars, but instead creates whole function temporaries. So we have in *.gimple: #pragma omp parallel num_threads(num_nthreads) shared(filenames) { char * D.2570; long unsigned int D.2571; { char filename[508]; int i; try { i = 0; D.2570 = filenames[i]; strcpy (&filename, D.2570); D.2571 = __builtin_strlen (&filename); D.2572 = &filename + D.2571; __builtin_memcpy (D.2572, "[data]", 7); } finally { filename = {CLOBBER}; } } where the D.2572 temporary has been created by fold_stmt, but it hasn't been added into the parallel region (nor has private(D.2572) clause which would work too). Right now in gimplify.c maybe_fold_stmt has a hack to avoid folding anything inside of ORT_TARGET regions, perhaps we should extend that also to (ctx->region_type & (ORT_PARALLEL | ORT_TASK)) != 0 too (and adjust lower_omp to fold_stmt accordingly even when taskreg_nesting_level is non-zero). Or get rid of fold_stmt during gimplification altogether, though that is supposedly not suitable for gcc 5 (and keep doing it only in forwprop and later)?