Re: compilation results with avr-gcc 4.8.3

Hi again,

I did some more testing and found that using

int main (void) {
    uint8_t reg;
    do {
        reg = PINx(I2C_PORT);  // macro translates to PIND
  6a:   80 b3           in      r24, 0x10       ; 16
    } while (((uint8_t) ~reg) & I2C_MASK);
  6c:   80 95           com     r24
  6e:   88 71           andi    r24, 0x18       ; 24
  70:   e1 f7           brne    .-8             ; 0x6a <main>

produces the intended result. Is it fair to conclude that the ~
operator, applied to an unsigned char, does produce an int as output
instead of the input type?

Could that be considered a bug, or is this in line with the C specification?

Regards,
Christian

On 25/09/14 18:20, Christian Schmidt wrote:
> Hi everyone,
> 
> I am currently porting some assembly code to C, using avr-gcc 4.8.3 on
> GNU/linux. While comparing the output I found some strangeness that
> persisted regardless of -Os, -O2 or -O3 optimization settings:
> 
> avr-objdump -h -S main.elf  (abbreviated)
> 
> #include <avr/io.h>
> 
> int main (void) {
>     unsigned char reg;
>     do {
>         reg = PIND;
>   38:   80 b3           in      r24, 0x10       ; 16
>     } while ((~reg) & 0x18);
>   3a:   90 e0           ldi     r25, 0x00       ; 0
>   3c:   80 95           com     r24
>   3e:   90 95           com     r25
>   40:   88 71           andi    r24, 0x18       ; 24
>   42:   99 27           eor     r25, r25
>   44:   89 2b           or      r24, r25
>   46:   c1 f7           brne    .-16            ; 0x38 <main>
> }
> 
> All those operations involving R25 are equivalent to NOPs? That's about
> half the instructions in this small example. Are there any compiler
> flags beyond general optimization levels I could set to avoid this?
> 
> Please CC: me on replies, as I am not subscribed to the list.
> 
> Best regards,
> Christian
>