On 05/05/14 09:05, Florian Weimer wrote:
On 03/03/2014 01:03 PM, Florian Weimer wrote:
I have code like this:
if (auth_info->attrs.pin.flags & SC_PKCS15_PIN_FLAG_SO_PIN) {
preferred = 1;
} else {
preferred = current;
/* PINs are even numbered, PUKs are odd */
if (!(preferred & 1))
preferred++;
if (preferred >= 126)
return SC_ERROR_TOO_MANY_OBJECTS;
}
if (current > preferred || preferred > CARDOS_PIN_ID_MAX)
return SC_ERROR_TOO_MANY_OBJECTS;
On x86_64, the condition in the final if statement is gimplified as:
- D.8003 = current > preferred;
- D.8004 = preferred > 15;
- D.8005 = D.8003 | D.8004;
- if (D.8005 != 0) goto <D.8006>; else goto <D.8007>;
On rs6000 (-mtune=power7 -mcpu=power7), I get this instead:
+ if (current > preferred) goto <D.8376>; else goto <D.8378>;
+ <D.8378>:
+ if (preferred > 15) goto <D.8376>; else goto <D.8377>;
Yes, this is a known issue. There's places where the costing models
change the gimple we initially generate and what transformations we
apply later.
Long term we want to push this stuff to a later point in the pipeline,
but there's some disagreement over exactly how/when to do that.
Jfef
