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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2018-07-30
                 CC|                            |law at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
We have the isolate-errorneous-paths pass which does:

example (const int & a)
{
  int _3;
  int _4;
  const int * _5;
  const int * _6;
  int _7;

  <bb 2> [local count: 1073741825]:
  _3 = *a_2(D);
  if (_3 == 0)
    goto <bb 3>; [100.00%]
  else
    goto <bb 4>; [0.00%]

  <bb 3> [local count: 598933193]:
  # _5 = PHI <a_2(D)(2)>
  _4 = *_5;
  return _4;

  <bb 4> [count: 0]:
  # _6 = PHI <0B(2)>
  _7 ={v} *_6;
  __builtin_trap ();

}

note how it doesn't eliminate the actual load which probably causes the 
odd code-generation.  Nothing removes it afterwards because it may
(and will!) trap.

Then isolate-errorneus-paths runs a bit late so the next CSE pass to
CSE *a_2(D) and *_5 is PRE.  But we still end up with the following
in the end, keeping the condition live.  As Marc said the condition
would be only dead if we'd use __builtin_unreachable () rather than
__builtin_trap () here which has security implications.  But the
load doesn't need to be there.

  <bb 2> [local count: 1073741825]:
  _3 = *a_2(D);
  if (_3 == 0)
    goto <bb 3>; [100.00%]
  else
    goto <bb 4>; [0.00%]

  <bb 3> [local count: 598933193]:
  return _3;

  <bb 4> [count: 0]:
  _7 ={v} MEM[(const int *)0B];
  __builtin_trap ();

Reply via email to