Re: [avr-gcc-list] odd behaviour with type casting

[Georg-Johann Lay]

Paul Thomas wrote:
> On Thu, Feb 23, 2012 at 4:42 PM, Georg-Johann Lay <address@hidden> wrote:
>> Paul Thomas schrieb:
>>> I'm getting very wrong math in one instance using a casting,  negative
>>> numbers and a division. If I don't do any 1 of those three things it
>>> works fine. This is with an atxmega32a4 using both the atmel avr-gcc
>>> 4.5.1 (avr-gcc (AVR_8_bit_GNU_Toolchain_3.2.3_314) 4.5.1) as well as
>>> 4.5.1 gcc built with the script from AvrFreaks. The code snippet to
>>> demonstrate this is: ...
>>
>> Without a minimal example that *compiles* and is legal C code no one will be
>> able to say anything about this.  Same for guessing the compiler options.
>>
>> With almost 99.9% certainty your problem is somewhere else; not in the
>> arithmetic and not in the cast.
>>
>> 4.5.x has PR46779 and PR39633 open, for example, but with obfuscated code
>> there is no clue...
>>
>> Johann
> 
> Here's the compiler options:
> avr-gcc -gdwarf-2 -Wall -Wno-attributes -O2 -mmcu=atxmega32a4
> -I./include -I../common/include    -c -o cpv.o cpv.c
> avr-gcc -gdwarf-2 -Wall -Wno-attributes -O2 -mmcu=atxmega32a4
> -I./include -I../common/include    -c -o ../common/avrpacket.o
> ../common/avrpacket.c
> avr-gcc -gdwarf-2 -Wall -Wno-attributes -O2 -mmcu=atxmega32a4
> -I./include -I../common/include    -c -o ../common/crc.o
> ../common/crc.c
> avr-gcc -gdwarf-2 -Wall -Wno-attributes -O2 -mmcu=atxmega32a4
> -I./include -I../common/include  -Wl,-Map,cpv.map -o cpv.elf cpv.o
> ../common/avrpacket.o ../common/crc.o
> avr-objdump -h -S cpv.elf > cpv.lst
> 
> I'll try and reduce this to a simple program, that can be compiled.
> The main thing is that uart_putchar (i.e. printf) is tied up in a
> custom interrupt/dma library, but I can just use a simple uart_putchar
> function for this.
> 
> thanks,
> Paul

There's no need to include hundreds of modules. If one module has the problem, 
then

* compile that with avr-gcc -v -c -save-temps ...
* Show the console output
* attach the preprocessed file foo.i
* attach the compiled file foo.s

If it is a compile bug, you will be able to show what instructions are wrong,
and there is no need to have a main or printf or UART wired or whatever.

To write a small test case, you can for example

#include <stdlib.h>

void foo (unsigned x)
{
   if (x < 0)
     abort();
   exit (0);
}

and compile that as described above where the abort() part shows the
malfunction and the exit part is the desired path when the compiler works
correctly.

You can add your private implementations of abort or any other functions in an
*other*, for example

void abort (void)
{
   uart_printf (...);
}

if you want to link and run the stuff.

But make sure you have as less as possible dependencies in the foo.c file.

It's some work for you, but with obfuscated code like above it's no avail.

Johann