compiler produce wrong code!

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

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:

0 Likes
7 Replies
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

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

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

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

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

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.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Hmmmmm... I have to think that over, but I do not understand why you need dynamite???

   

 

   

Bob

0 Likes