David Brown <david.br...@hesbynett.no> 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. ;-) _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
