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
Mats Erik Andersson wrote:
after much backtracking I have identified an unexpected case of (implicit) casting where romcc fails miserably.
Great work!
In the light of all this, I mean to have found a bug in romcc,
No doubt. Did your research so far allow you to also suggest a fix?
//Peter
On Fri, Sep 12, 2008 at 5:40 AM, Peter Stuge peter@stuge.se wrote:
Mats Erik Andersson wrote:
after much backtracking I have identified an unexpected case of (implicit) casting where romcc fails miserably.
Great work!
In the light of all this, I mean to have found a bug in romcc,
No doubt. Did your research so far allow you to also suggest a fix?
romcc is end of life and unmaintained for many years now.
I think it is a mistake to change something this fundamental unless you can test it across platforms. There may be code out there that depends on this bug ....
ron
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
On 12.09.2008 14:59, Andriy Gapon wrote:
on 12/09/2008 15:30 Mats Erik Andersson said the following:
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.
did you by a chance confused '&' and '&&" as in your examples?
I believe Andriy is right. The expected outcome of the calculation above is indeed 1.
Regards, Carl-Daniel
ron minnich wrote:
In the light of all this, I mean to have found a bug in romcc,
No doubt.
(Yes, doubt.)
Did your research so far allow you to also suggest a fix?
romcc is end of life and unmaintained for many years now.
I think it is a mistake to change something this fundamental unless you can test it across platforms. There may be code out there that depends on this bug ....
That is a really good point.
Carl-Daniel Hailfinger wrote:
did you by a chance confused '&' and '&&" as in your examples?
I believe Andriy is right. The expected outcome of the calculation above is indeed 1.
I agree. Well done noticing the extra &!
//Peter
Mats Erik Andersson wrote:
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.
1 is very much the expected result because the above is a boolean expression, not a bitwise AND.
Looks like a bug in the 440bx ram init code.
Stefan
Stefan Reinauer skrev alldeles nyss
Mats Erik Andersson wrote:
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.
1 is very much the expected result because the above is a boolean expression, not a bitwise AND.
Looks like a bug in the 440bx ram init code.
Stefan
Very true indeed. I made a mistake with the logical connective. Let there henceforth be silence on this embarrassing event, since the casting indeed is proven correct when my misprint has been corrected. Very sorry for the noise!
Kind regards,
Mats E Andersson
-
Andriy Gapon -
Carl-Daniel Hailfinger -
Mats Erik Andersson -
Peter Stuge -
ron minnich -
Stefan Reinauer