Re: [avr-gcc-list] possible optimize bugg

[David Brown]

On 16/01/18 12:50, georg chambert wrote:
> Hi Erik,
> I have a related question; is there any interrest for the avr dev
> community to find & corr buggs;
> since I could easily work around this, and leave it be.

The avr-gcc developers are always interested in people helping to find
and correct bugs.  And they are always interested in trying to correct
bugs themselves, especially if there is incorrect code generation.

However, you haven't given any indication of compiler problems of any
sort.  Clearly English is not your first language - you will have to
take a bit more time to explain your issue.

In order to be able to help, people will need:

1. A /full/ source listing that can be compiled, and which demonstrates
your problem.  This should be as short as possible while still having
the issue that you see.

2. Details of the compiler version used, and of the command-line
switches used.

3. A clear description of what you expected, and what you think went wrong.

Remember that a compiler is not a mindless translator.  Just because you
wrote code using loops, does not mean the output will be loops.  If the
compiler can see common parts in the messages you have here, it might be
combining them.  Usually such things are done to make code more
efficient - smaller /and/ faster.  Sometimes it will be smaller but
slower, sometimes faster but bigger - that depends on the code in
question and the switches used.

Hopefully that will help you make a better post, and then people have a
chance of helping you.

mvh.,

David


> The fault I think I have encountered, is some opt. that realizes that
> these are same statements over and over
> and tried to put code making this more efficient. Essentially I  move 4
> elementes (bytes) from 7 different
> arrays, into yet another array (of 4 elsements), depending on a select
> parameter.
> The move is done by the for(i....) loop. I have tried to follow the
> assembler in the .lst file (from the .o),
> but thats a bit tricky, expecially since the insertion of the original
> C-lines are quite randomly scattered into
> the resulting asm. However there seem to be some elaborate
> thinking/coding going on, rather than a highy repetitive action
> which I had expected. and all the 7 "if() for()  " statements are lumped
> together.
> 
> ----- Original Message ----- From: "Erik Christiansen"
> <address@hidden>
> To: <address@hidden>
> Sent: Tuesday, January 16, 2018 4:59 AM
> Subject: Re: [avr-gcc-list] possible optimize bugg
> 
> 
>> Reply-To: address@hidden
>>
>> On 16.01.18 01:17, georg chambert wrote:
>>>
>>> msg_on[0] = 0b10001000; // address
>>>
>>> msg_on[1] = 0b00000000; // PWZS Tmmm : (?) mmm = cool
>>>
>>> msg_on[2] = 0b10000100; // tttt,vvvv ; 23c , high vent
>>>
>>> msg_on[3] = 0b11000000; // pppp, 0 ; parity
>>>
>>> -----  etc for 6 more messages ----
>>
>> ...
>>
>>> if (msg_nbr == 0) for (i=0;i<4;i++) seq[i] = msg_off[i]; // load a
>>> selected message to send (off)
>>
>> No information provided on msg_off, so no diagnosis possible.
>>
>>> //if (msg_nbr == 1) for (i=0;i<4;i++) seq[i] = msg_on[i]; //
>>
>> This is the only line which addresses the msg_on array.
>>
>>> //if (msg_nbr == 2) for (i=0;i<4;i++) seq[i] = msg_on26[i]; //
>>>
>>> //if (msg_nbr == 3) for (i=0;i<4;i++) seq[i] = msg_on1[i]; //
>>>
>>> //if (msg_nbr == 4) for (i=0;i<4;i++) seq[i] = msg_on2[i];
>>>
>>> //if (msg_nbr == 5) for (i=0;i<4;i++) seq[i] = msg_on3[i];
>>>
>>> if (msg_nbr == 6) for (i=0;i<4;i++) seq[i] = msg_on4[i];
>>
>> No information provided on msg_on4, a different array, so no diagnosis
>> possible.
>>
>>> When I comment out the inbetween statements the last one for 6, works,
>>> else the data in seq array is not what  I just put the msg_on4 just
>>> before.
>>
>> You might try: $ nm yourfile.elf | grep msg_on
>> then compare the values for msg_on and msg_on4.
>> If you have made them the same address, in a way not shown, then the
>> same data could be expected, if I understand what you're trying to do.
>>
>> Erik
>>
>>
>> _______________________________________________
>> AVR-GCC-list mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/avr-gcc-list