... Enquiring minds like to know what machine code they are generating. Very instructional, and at times essential. ...

Yes. With the assembly listing one could tune short programs to work efficiently. When we use a timer with 16 Mhz frequency we could even count CPU cycles easily. It is also fascinating to see how the compiler optimizes the code. I wrote a timing exercise:

So, with 1.5.x, it should be trivial to cause assembly listings to be generated at compile time, and not too difficult to cause a disassembly at the end of the build process. (when it works, I tend to find the disassembly more useful than the compiler-produced output.)

...(when it works, I tend to find the disassembly more useful than the compiler-produced output.)

More useful? When in doubt about the code produced, I would (also) trust the disassembly more. Or do you see other reasons for being more useful?---When trying to optimize interrupt service routines to be as fast as possible, it is nice to see, how the compiler is smart enough to save/restore only those registers which are really needed. E.g. incrementing 4 byte volatile timer variable can be done in about 39 cycles of 62.5 ns. If an overflow interrupt happens every 256 cycles there is reason to think how to code: 39/256 is about 15 % of total cpu-cycles. However, premature optimization is a source of many unnecessary and complicated code sequences. But ah so interesting!

The assembler listing from the compiler:1) is full of debugging info and "noise"2) is pre-link, which means some optimization might not have been done ("relax"?), and absolute jump/call destinations are not filled in. Also, doesn't have the unused functions omitted by "gc-sections"3) doesn't have the full program including libraries.