- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The code I show create endless loop (line 671 branch to line above)
Innocent end of switch statement:
case TSH:
// some calculations
break;
default:
break;
}
And assembly:
664 01e6 FFF7FEFF bl mymemcpy
665 .LVL57:
217:.\Uart.c **** break;
666 .loc 1 217 0
667 01ea 00E0 b .L23
668 .LVL58:
669 .L26:
670 .L80:
671 01ec FEE7 b .L80
672 .LVL59:
673 .L23:
674 .LBE23:
231:.\Uart.c **** }
675 .loc 1 231 0
676 @ sp needed for prologue
677 .LVL60:
678 01ee F7BD pop {r0, r1, r2, r4, r5, r6, r7, pc}
679 .L85:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It looks as if undocumented trap to catch wrong jumps
I trace the condition it may happen. I found label .L26 is referenced in other function unrelated at all
In this function there is do{}while(rdindx != wrindx)
when condition is true instead of jump to begin of loop it jumps to end of swithc statement in different function
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I found the reason somwhere else:
Somehow the copy & paste inserted the code twice, and the code produced was
void ParseInput(Cmd* ptr){
while(rdindx != wrindx){
}
uint16 sum = 0;
uint8 indx;
...........................
I have no idea while it compiled without even warning.
However it was the endless loop
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sego,
I think you can be darn sure that GCC is not producing wrong code, GCC is used in a billion of cellphones, so any obvious bug would have been found already. From your code snippets I cannot see where the real error has been, probably you've set an optimization which sometimes lead to results which work correctly but are difficult to understand.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Bob, if I google "gcc eratta" I get lots of hits, some fairly recent ?
If I go to http://gcc.gnu.org/ more info on bugs/fixes.
Seems like still a work in progress.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I said "any obvious bug"
But when you take the time to go through the recent / open bugs in GCC there are just two for the ARM-core. Most of the issues are related to the behavour of flags applied, linux and x86 or compiler build. I just finished a rather complicated project that dwelves deep into ARM architecture and the only errors I found where my own ones.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I will take your word there will be no more obvious bugs, just thought that
was too broad a statement.
So my postulate is this, do not all bugs (once discovered) become obvious ? I think I will
submit this to Nobel comittee, I think I have a winner on my hands......
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hmmmmm... I have to think that over, but I do not understand why you need dynamite???
Bob