Sorry for top posting - did you by a chance confused '&' and '&&" as in your examples below?
on 12/09/2008 15:30 Mats Erik Andersson said the following:
Hello all,
after much backtracking I have identified an unexpected case of (implicit) casting where romcc fails miserably.
I desire a computation
uint16_t fn(uint8_t d);
uint8_t data;
data = 0; data += ( fn(0x10) >> 1 ) && 0x007f;
where fn(0x10) == 0x1010. However, the actual outcome of the previous calculation is the value 0x01, instead of the expected 0x08. I does not help to provide an explicit casting
data += (uint8_t) ( fn(0x10) >> 1) && 0x007f;
since provably the incorrect increment 0x01 is still produced.
The above code is to be used in i440bx/raminit.c, and if I make the only change in that code to replace the above calculation with the fixed, but intended case
data += 0x08;
then the full functionality is restored and coreboot can start.
In the light of all this, I mean to have found a bug in romcc, unless this can be viewed as a documented shortcoming.
Best regards,
Mats Erik Andersson
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot