I've stumbled across a ROMCC bug that results in incorrect code being generated. As near as I can tell, multi-layer "if" statements are at risk of being miscompiled when optimization is enabled. The following program snippet induces the bug when compiled via "romcc -mcpu=p4 -O2" (or -O):
/************************************************/ void die(void) { }
static void miscompiled_function(unsigned short param) { unsigned int data = __builtin_inl(0); if (data == 0) param = 12; else if (data == 4) param = 42; else die();
__builtin_outl(param, 0); }
static void internal_compiler_error(unsigned short param) { unsigned int data = __builtin_inl(0); if (data == 0) param = 12; if (data == 4) param = 42; if ((data != 0) && (data != 4)) die();
__builtin_outl(param, 0); }
void main(void) { miscompiled_function(0); // internal_compiler_error(0); }
/************************************************/
The assembly output for the miscompiled function is such that when data == 4, param is set to zero, instead of 42.
The function 'internal_compiler_error' is logically equivalent to 'miscompiled_function', but attempting to call it results in the following message:
bug.c:20.1: bug.c:36.32: warning: edge: bug.c:20.1: bug.c:36.32: warning: 0x9e53b08 copy :0.0: warning: 0x9e542d8 convert <built-in>:1.0: bug.c:21.42: bug.c:36.32: warning: def: <built-in>:1.0: bug.c:21.42: bug.c:36.32: warning: 0x9e53ea8 __inl <built-in>:1.0: bug.c:21.42: bug.c:36.32: 0x9e53ea8 __inl Internal compiler error: live range with already used color %eax Aborted
----------------------------- Steve Magnani www.digidescorp.com
This logically-equivalent function appears to compile correctly.
static void proper_function(unsigned short param) { unsigned int data = __builtin_inl(0);
switch (data) { case 0: param = 12; break;
case 4: param = 42; break;
default: die(); break; }
__builtin_outl(param, 0); }
So we must make cache_as_ram work on other 86 platform besides amd cpu...
Is there any intel public doc about using cache_as_ram?
I have tried amd cache_as_ram in intel platform, it seem if access some position several times, the contents of that address will become to 0xff....
YH
On 6/17/05, Steve Magnani steve@digidescorp.com wrote:
This logically-equivalent function appears to compile correctly.
static void proper_function(unsigned short param) { unsigned int data = __builtin_inl(0);
switch (data) { case 0: param = 12; break; case 4: param = 42; break; default: die(); break; } __builtin_outl(param, 0);}
LinuxBIOS mailing list LinuxBIOS@openbios.org http://www.openbios.org/mailman/listinfo/linuxbios
* yhlu yinghailu@gmail.com [050618 05:53]:
So we must make cache_as_ram work on other 86 platform besides amd cpu...
I have tried amd cache_as_ram in intel platform, it seem if access some position several times, the contents of that address will become to 0xff....
AFAICR, Intel has not been as thorough with their design wrt cache as ram. LinuxBIOS v1 has some mainboards doing CAR, but it was hard to maintain because the Xeons changed their behaviour with every stepping.. This might very well have improved by now, hard to say, as Intel specs are hard to get.
Stefan
yhlu yinghailu@gmail.com writes:
So we must make cache_as_ram work on other 86 platform besides amd cpu...
It is a good idea and for new cpus it is probably an option. For people in the embedded space we still need romcc.
Is there any intel public doc about using cache_as_ram?
I have not seen any yet which is a puzzle. For the first round of Intel cpus that supported it you had to load a microcode update, before it would work. I have yet to see if AMD's flavor will work on k8 revisions B3, C0, CG, Ex. I expect it will but I have been burnt too many times.
I have tried amd cache_as_ram in intel platform, it seem if access some position several times, the contents of that address will become to 0xff....
Exactly the problem. If you aren't using a supported flavor of cache as ram it fails more often and in less predictable ways than romcc. That is why I avoid it unless the manufacturer supports it. And that is why we cannot decompress and run code out of the cache.
Eric
AMD i have tried c0 and Ex.
On 6/20/05, Eric W. Biederman ebiederman@lnxi.com wrote:
yhlu yinghailu@gmail.com writes:
So we must make cache_as_ram work on other 86 platform besides amd cpu...
It is a good idea and for new cpus it is probably an option. For people in the embedded space we still need romcc.
Is there any intel public doc about using cache_as_ram?
I have not seen any yet which is a puzzle. For the first round of Intel cpus that supported it you had to load a microcode update, before it would work. I have yet to see if AMD's flavor will work on k8 revisions B3, C0, CG, Ex. I expect it will but I have been burnt too many times.
I have tried amd cache_as_ram in intel platform, it seem if access some position several times, the contents of that address will become to 0xff....
Exactly the problem. If you aren't using a supported flavor of cache as ram it fails more often and in less predictable ways than romcc. That is why I avoid it unless the manufacturer supports it. And that is why we cannot decompress and run code out of the cache.
Eric
"Steve Magnani" steve@digidescorp.com writes:
I've stumbled across a ROMCC bug that results in incorrect code being generated. As near as I can tell, multi-layer "if" statements are at risk of being miscompiled when optimization is enabled. The following program snippet induces the bug when compiled via "romcc -mcpu=p4 -O2" (or -O):
Thanks. I will take a look.
This looks similar to another bug I am tracking as well. For that bug by specifying -fno-simplify-phi I was able to avoid the problem. For that bug I got as far a deciding that there was an interaction bug between several optimizations that appear correctly in and of themselves.
I will take a look at what you have given me, as it looks like a nice test case, and see what I can find. I suggest you play with disabling individual optimizations so you can at least move forward until this bug is fixed.
Eric
-
ebiederman＠lnxi.com -
Stefan Reinauer -
Steve Magnani -
yhlu