Diego Novillo wrote:
> I'm puzzled about this one. The dump machinery was registering
> pass_lower_omp as an RTL pass. And this was happening *only* because I
> was having pass_lower_omp mark PROP_gimple_any destroyed.
> Now, why doesn't this happen to pass_lower_cf? I cut-n-pasted this from
> that one, originally.
I don't have the branch checked out, but is PROP_gimple_lomp part of
> Paolo, any ideas why the dump machinery got confused? The pass itself
> ran fine, but it would not react to -fdump-tree-omplower. It would
> only accept -fdump-rtl-omplower and then ICE.
Which is kind of expected, because it was trying to dump RTL. :-)
>>I don't have the branch checked out, but is PROP_gimple_lomp part of
> I tried that, too. But it didn't seem to affect things. I'll try again
> with a clean build.
The reason is that the properties after pass_lower_omp are
PROP_gimple_any if pass_lower_omp did not run, and PROP_gimple_lomp if
pass_lower_omp has run. register_dump_files sees that pass_lower_omp
has a gate so it takes the "and" of the two to be conservative, and the
result is zero -- no PROP_gimple_any, no PROP_gimple_lomp.
pass_lower_cf has no gate, so it works. Likewise for pass_lower_eh.
I think that (in retrospect) it was not a good decision to have *only*
mutually exclusive bits PROP_gimple_any, PROP_gimple_lcf,
PROP_gimple_leh. It would be better to have a single bit
PROP_gimple_any that is always set for GIMPLE code, and then set
PROP_gimple_lcf, PROP_gimple_leh, PROP_gimple_lomp *in addition* to
I guess for the branch, the solution is just to not have
PROP_gimple_lomp? When it is merged, I would take care of fixing it.
Some of this will already be more intuitive in 4.2 after the dump file
naming will be according to your suggestions, and I'll clean up the ugly
code that was only there to keep the old RTL dump file names.