--- Comment #7 from dnovillo at gcc dot gnu dot org 2005-11-19 15:18
---
Workaround applied.
The actual solution separates lowering from optimization, once all the OMP
directives are lowered to a language-independent form, we can apply the
combined parallel+loop optimization without r
--- Comment #6 from dnovillo at gcc dot gnu dot org 2005-11-19 15:18
---
Subject: Bug 24849
Author: dnovillo
Date: Sat Nov 19 15:18:08 2005
New Revision: 107220
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107220
Log:
PR 24849
* omp-low.c (determine_parallel_
--- Comment #5 from reichelt at gcc dot gnu dot org 2005-11-17 10:02
---
Here's a shorter testcase without templates:
==
void foo()
{
#pragma omp parallel
{
int i, N;
#pragma omp for schedule (dynamic)
for (i=0; ihttp://gcc.gn
--- Comment #4 from dnovillo at gcc dot gnu dot org 2005-11-16 15:57
---
Working on this.
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
Assign
--- Comment #3 from martin at mpa-garching dot mpg dot de 2005-11-15 09:07
---
Some more information:
- I didn't encounter the bug about a week ago
- on x86_64 with checking disabled, I get
[EMAIL PROTECTED]:~/martin> g++ -c -v -fopenmp test.cc
Using built-in specs.
Target: x86_64-unk
--- Comment #2 from jakub at gcc dot gnu dot org 2005-11-15 08:59 ---
The problem here is a mismatch between determine_parallel_type in gimplify.c
and omp-low.c. During gimplification, it is not considered to be a combined
parallel loop, because OMP_PARALLEL's body contains a DECL_EXPR
--- Comment #1 from martin at mpa-garching dot mpg dot de 2005-11-14 15:14
---
> gcc version 4.1.0-gomp-20050608-branch 20051109 (experimental) (merged
20051109)
BTW, it appears as if the compiler datestamp is not correctly updated on
the gomp branch (it says 20051109, but there have b
