avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Re: sprintf


From: Joerg Wunsch
Subject: Re: [avr-gcc-list] Re: sprintf
Date: Fri, 6 Mar 2009 06:30:48 +0100 (MET)

David Brown <address@hidden> wrote:

> Rather than waffling more about what I thought or expected to
> happen, I tried out a couple of cases.  I've pasted my test code at
> the bottom of this post.

Thanks!

> With avr-gcc 4.3.2, test3() below gave a "warning: array subscript is 
> above array bounds" warning.

Yes, I can also see it.  As GCC 4.2 doesn't generate it, it appears to
be a relatively new feature of GCC.

>  When taking the address of an array 
> element or using pointer arithmetic, no warning is given.  This makes 
> sense as far as I understand the C standards - attempting to access an 
> array beyond its bounds is illegal, but adding an integer to a pointer 
> is always legal despite its values.

Nope.  Accessing something through a pointer that points into
unallocated memory causes undefined behaviour.  While the standard has
(of course) no guidelines for when to issue a warning, detecting
undefined behaviour would always warrant a warning.  Your example
shows, though, that GCC doesn't handle both situations the same (even
though it probably could).  This might or might not be easy to fix --
I'd leave that to those who understand the compiler better than me.
I'm happy enough to understand larger portions of the C standard. :-)

> With avr-gcc 4.2.2, foo1, foo2 and foo3 all generated the unrolled
> loop, while foo4 generated the full loop above.

Yes, I also noticed this.  It also unrolls foo4() when compiling with
-O3.  Same for GCC 4.3, it also unrolls all loops with -O3.

The speed/size tradeoff is often based on heuristics, and
unfortunately (for us), these heuristics are usually determined on
GCC's mainstream targets so they don't fully apply to us.

> Neither compiler produced the smarter possibility:
> 
>       lds r24, as+1
>       ldi r30, lo8(bs)
>       ldi r31, hi8(bs)
>       st Z+, r24
>       st Z+, r24
>       st Z+, r24
>       st Z+, r24
>       ret

Because apparantly, nobody has generated a pattern for that case.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]