https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87188
--- Comment #13 from dave.anglin at bell dot net --- On 2018-09-05 8:50 AM, jamborm at gcc dot gnu.org wrote: > Then I believe SRA is not the culprit, you probably need to trace what > happens to SR.13 afterwards and whether it is correctly expanded to > RTL. I did some more investigation. It looks like the ifcombine pass does a bad transformation: <bb 4> [local count: 1014686024]: SR.13_1 = MEM[(const struct &)itCO_2 + 8]; SR.14_7 = MEM[(const struct &)itCO_2 + 12]; if (SR.13_1 == operator!=) goto <bb 5>; [30.00%] else goto <bb 6>; [70.00%] <bb 5> [local count: 304405807]: if (SR.14_7 == 0) goto <bb 7>; [5.50%] else goto <bb 6>; [94.50%] transforms to <bb 4> [local count: 1014686024]: SR.13_1 = MEM[(const struct &)itCO_2 + 8]; SR.14_7 = MEM[(const struct &)itCO_2 + 12]; _13 = SR.14_7 == 0; _12 = SR.13_1 == operator!=; _14 = _12 & _13; if (_14 != 0) goto <bb 6>; [1.65%] else goto <bb 5>; [98.35%] Doing a "&" operation on a function pointer looks bad.
