Hi, so you wanted an *.i* file, I don't think this will be helpful. Anyway I appended it. I have a structure like this: function call <- inline function <- inline function. If the first Inline function (Button::Poll that is) passes a const number as parameter pin_number to the second function (Port::get_pin) that is, then the Poll::get_pin function returns *port_address & (1<<pin_number). That masks the appropiate pin in the port (bit in byte). However that will be static, but only optimize to some right rotates and then a compare against zero. It would be possible to just use the AVR's sbis (if bit is set) and provide the pin_number. And in fact that is the case when I call get_pin with (1<<pin_number) as parameter and don't do the shifting in the second-level inline function (but in the first). I hope you understand what I mean. This issue might also apply to other Platforms where this could be optimized. My command was : ./avr-gcc-4.6.0 -S -mmcu=atmega8 -Os /home/oliver/AVR/io/test.cc -save-temps -v and it's output: Using built-in specs. COLLECT_GCC=./avr-gcc-4.6.0 COLLECT_LTO_WRAPPER=/usr/local/avr/libexec/gcc/avr/4.6.0/lto-wrapper Target: avr Configured with: ../configure --target=avr --prefix=/usr/local/avr --disable-nls --enable-languages=c,c++ --disable-libssp : (reconfigured) ../configure --target=avr --prefix=/usr/local/avr --disable-nls --enable-languages=c,c++ --disable-libssp Thread model: single gcc version 4.6.0 (GCC) COLLECT_GCC_OPTIONS='-S' '-mmcu=atmega8' '-Os' '-save-temps' '-v' /usr/local/avr/libexec/gcc/avr/4.6.0/cc1plus -E -quiet -v -imultilib avr4 /home/oliver/AVR/io/test.cc -mmcu=atmega8 -Os -fpch-preprocess -fno-rtti -fno-enforce-eh-specs -fno-exceptions -o test.ii ignoring nonexistent directory "/usr/local/avr/lib/gcc/avr/4.6.0/../../../../avr/include/c++/4.6.0" ignoring nonexistent directory "/usr/local/avr/lib/gcc/avr/4.6.0/../../../../avr/include/c++/4.6.0/avr/avr4" ignoring nonexistent directory "/usr/local/avr/lib/gcc/avr/4.6.0/../../../../avr/include/c++/4.6.0/backward" ignoring nonexistent directory "/usr/local/avr/lib/gcc/avr/4.6.0/../../../../avr/sys-include" #include "..." search starts here: #include <...> search starts here: /usr/local/avr/lib/gcc/avr/4.6.0/include /usr/local/avr/lib/gcc/avr/4.6.0/include-fixed /usr/local/avr/lib/gcc/avr/4.6.0/../../../../avr/include End of search list. COLLECT_GCC_OPTIONS='-S' '-mmcu=atmega8' '-Os' '-save-temps' '-v' /usr/local/avr/libexec/gcc/avr/4.6.0/cc1plus -fpreprocessed test.ii -quiet -dumpbase test.cc -mmcu=atmega8 -auxbase test -Os -version -o test.s -fno-rtti -fno-enforce-eh-specs -fno-exceptions GNU C++ (GCC) version 4.6.0 (avr) compiled by GNU C version 4.6.1 20110526 (prerelease), GMP version 5.0.1, MPFR version 3.0.1-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (GCC) version 4.6.0 (avr) compiled by GNU C version 4.6.1 20110526 (prerelease), GMP version 5.0.1, MPFR version 3.0.1-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: bed1f0f30349434b4d9bd9c4315cba61 COMPILER_PATH=/usr/local/avr/libexec/gcc/avr/4.6.0/:/usr/local/avr/libexec/gcc/avr/4.6.0/:/usr/local/avr/libexec/gcc/avr/:/usr/local/avr/lib/gcc/avr/4.6.0/:/usr/local/avr/lib/gcc/avr/ LIBRARY_PATH=/usr/local/avr/lib/gcc/avr/4.6.0/avr4/:/usr/local/avr/lib/gcc/avr/4.6.0/../../../../avr/lib/avr4/:/usr/local/avr/lib/gcc/avr/4.6.0/:/usr/local/avr/lib/gcc/avr/4.6.0/../../../../avr/lib/ COLLECT_GCC_OPTIONS='-S' '-mmcu=atmega8' '-Os' '-save-temps' '-v' Have fun!
duplicate of 33049 *** This bug has been marked as a duplicate of bug 33049 ***
Not very helpful without source to reproduce, see http://gcc.gnu.org/bugs/#need
Seems that it is no duplicate. additional files test.ii (intermediate) http://pastebin.com/ZPV521si test.s (output) http://pastebin.com/DDFW0FCU compiler-output (verbose) http://pastebin.com/XHNPB6WX
Created attachment 24556 [details] output assembly, notice the unnecessary bitshifts
Created attachment 24557 [details] intermediate file
compiler output with gcc-4.7.0 : http://pastebin.com/XHNPB6WX
This issue is similar to PR33049 and con be caught by implementing extzv pattern. *** This bug has been marked as a duplicate of bug 33049 ***