[Bug c++/49575] OpenMP has a problem with -funroll-loops

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-06-29 19:49:47 UTC ---
With firstprivate of course you get a copy of the variable, but it is still a
variable.  The *.omp_fn* function which is created from the #omp parallel
region will load it from parameter's structure and use it:
  k = .omp_data_i->k;
...
  D.1646 = (double) k;
  i.33 = i + (long double) D.1646;
  temp.34 = pow (D.1646, 2.0e+0);
  i.36 = i.33 + (long double) temp.34;
  temp.37 = pow (D.1646, 3.0e+0);
  i.39 = i.36 + (long double) temp.37;
  temp.40 = pow (D.1646, 4.0e+0);
  i.42 = i.39 + (long double) temp.40;
  temp.43 = pow (D.1646, 5.0e+0);
...
but as it doesn't look at the caller, k is variable for it.  Without -fopenmp,
ccp propagates the 0.7 value to k uses and we end up with:
  i.32 = i + 6.999999999999999555910790149937383830547332763671875e-1;
  i.33 = i.32 + 4.89999999999999935607064571740920655429363250732421875e-1;
  i.34 = i.33 + 3.42999999999999916067139338338165543973445892333984375e-1;
  i.35 = i.34 + 2.400999999999999523492277830882812850177288055419921875e-1;
  i.36 = i.35 + 1.680699999999999416644413940957747399806976318359375e-1;
  i.37 = i.36 + 1.1764899999999996194066653742993366904556751251220703125e-1;
  i.38 = i.37 + 8.23542999999999636440151107308338396251201629638671875e-2;
...
because gcc saw pow (0.7, 2.0e+0), pow (0.7, 3.0e+0); etc. and constant folded
that.  So, there aren't any pow calls without -fopenmp (wonder why nothing
folded even the additions with -ffast-math though).  Now, if with -fopenmp we
do an interprodecural optimization so that .omp_data_i->k loads in the callee
are replaced with what constant value has been stored into that field after
constant propagation is performed in the caller, we can again constant
propagate the 0.7 down into the pow calls and constant fold them.
Of course the testcase doesn't make any sense this way, but the constant
propagation accross the parallel region boundary could help real-world OpenMP
programs too.