https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442

--- Comment #35 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
On 

#include <vector>
bool test1(const std::vector<int>& in) {
    return in == std::vector<int>{42};
}


we produce:
bool test1 (const struct vector & in)
{
  bool _12;
  int * _13;
  int * _14;
  long int _24;
  unsigned int _43;
  int * _50;
  unsigned int _64;
  bool iftmp.5_69;

  <bb 2> [local count: 1073741824]:
  _50 = operator new (4);
  MEM <unsigned int> [(char * {ref-all})_50] = 42;
  _13 = MEM[(int * *)in_6(D)];
  _14 = MEM[(int * *)in_6(D) + 8B];
  _24 = _14 - _13;
  if (_24 == 4)
    goto <bb 3>; [34.00%]
  else
    goto <bb 4>; [66.00%]

  <bb 3> [local count: 182536112]:
  _43 = MEM <unsigned int> [(char * {ref-all})_13];
  _64 = MEM <unsigned int> [(char * {ref-all})_50];
  _12 = _43 == _64;

  <bb 4> [local count: 1073741824]:
  # iftmp.5_69 = PHI <_12(3), 0(2)>
  operator delete (_50, 4);
  return iftmp.5_69;

}

Allocation is not removed because we store 42 to the block:
  MEM <unsigned int> [(char * {ref-all})_50] = 42;
and later read it again
  _64 = MEM <unsigned int> [(char * {ref-all})_50];

I think this is pass ordering issue.  At PRE time we have
  _61 = __builtin_memcmp (_13, _50, 4);
eventually it is taken away by strlen pass, but there is no another FRE to
handle this scheduled after strlen.

Reply via email to