Amongst the inputs to the analyzer state machines that can lead to state
transitions are conditions on CFG edges, such as a test for a pointer
being non-NULL.

These conditionals can be non-trivial to determine in the face of
optimization.  For example, at -O2:

  if (p == NULL || q == NULL)

is optimized on some targets (e.g. x86_64) to a bitwise-or:

  _1 = p_5(D) == 0B;
  _2 = q_6(D) == 0B;
  _3 = _1 | _2;
  if (_3 != 0)
    goto <bb 4>; [51.12%]
  else
    goto <bb 3>; [48.88%]

but on other targets (e.g. powerpc64le) as control flow:

  if (p_2(D) == 0B)
    goto <bb 5>; [18.09%]
  else
    goto <bb 3>; [81.91%]

  <bb 3> [local count: 879501929]:
  if (q_3(D) == 0B)
    goto <bb 5>; [30.95%]
  else
    goto <bb 4>; [69.05%]

region_model::add_any_constraints_from_ssa_def_stmt attempts to walk
SSA def chains to reconstruct the conditions that hold, so that
e.g. in the above case of bitwise-or, the state machine for
"p" can transition to the "known-null" state along the edge leading
to bb 3.

In gcc.dg/analyzer/pattern-test-2.c I attempted to write test coverage
for this, but the test fails on those targets for which the || is
expressed via control flow.

This patch rewrites the test to make explicit use of bitwise-or, and
adds coverage for bitwise-and for good measure.

gcc/testsuite/ChangeLog:
	PR analyzer/93291
	* gcc.dg/analyzer/pattern-test-2.c: Remove include of stdlib.h.
	(test_2): Rewrite to explicitly perform a bitwise-or of two
	boolean conditions.
	(test_3): New function, to test bitwise-and.