------- Comment #20 from rguenth at gcc dot gnu dot org 2008-01-14 16:55
-------
So even if you fix that, and you'll end up with
<unnamed-unsigned:24> D.2029;
<bb 2>:
D.2029 = (<unnamed-unsigned:24>) (unsigned int) ((int) x.i + -1);
x.i = D.2029;
if (D.2029 != 16777215)
goto <bb 3>;
else
goto <bb 4>;
before expand, the truncation at the store to register D.2029 still is
not reflected in code generated by expand, if the language does not
have REDUCE_BIT_FIELD_OPERATIONS set.
Which means that the GIMPLE IL
bool retval.0;
<unnamed-unsigned:24> D.2025;
int D.2026;
int D.2027;
unsigned int D.2028;
<unnamed-unsigned:24> D.2029;
unsigned int D.2030;
unsigned int D.2031;
D.2025 = x.i;
D.2026 = (int) D.2025;
D.2027 = D.2026 + -1;
D.2028 = (unsigned int) D.2027;
D.2029 = (<unnamed-unsigned:24>) D.2028;
x.i = D.2029;
D.2025 = x.i;
retval.0 = D.2025 != 16777215;
if (retval.0)
still does not have frontend independent semantics. IMHO this is a
middle-end bug.
Let's hope that the IL fix remove the issues with libjava you get into
if enabling the langhook for C++.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
