Tricky testcase

Jan Hubicka
Mon Oct 9 12:16:00 GMT 2000

I've managed to construct testcase for VOIDmodes versus comparison problem
in gcc.  The testcase is:

int a,b;
  int c=-2;
  int d=0xfe;
  int e=a&1;
  int f=b&2;
  if ((char)(c|(e&f)) == (char)d)
    return 0;

And works by forcing combine to decide comparison that gets simplified to
(eq (const_int 0xfe) (const_int -2))
that holds only for QImode.  Since combine works by putting whole compare
expression into the operator as:
  (eq (compare:CC (reg:QI) (const_int -2)) (const_int 0))
After one extra substitution to:
  (eq (compare:CC (const_int 0xfe) (const_int -2)) (const_int 0))
At this point combine still knows proper mode of compare, but fails to simplify
it, so returns one level upwards to eq, that is now believed to be CCmode
comparison.  Cmbine manages to rewrite it to
  (eq (const_int 0xfe) (const_int -2))
and detects mode according to the first operand, that is VOIDmode.
Simplify_replational_operation now gets VOIDmode comparison and predicts it in
the "infinite" precisity, thus false.

Similar problems exist at a lot of other places in compiler and only corect
fix I see is to prohibit VOIDmode in simplify_relational_operation as I did.
The resulting patch is large and got unreviewed for few months, so now I would
like to send it in smaller pieces and with this testcase as an illustration
of the real problem.

First part is the validate_replace_rtx_1 fix, that is just about top of iceberg
and about 100kb of followup patches will follow in case no one will come with
better solution.

This testcase is sent basically to motivate you to follow this path and get
this latent bug fixed soon.


More information about the Gcc-patches mailing list