------- Comment #9 from shcherbakov at daad-alumni dot de 2010-01-30 22:48 ------- In general 'black box' case - yes. However, here there are 2 factors: 1) It is clear from the sources that 2 similar situations (pre-decrement and post-increment) are handled in a different way, an additional check performed in pre-decrement is forgotten in post-increment mode. 2) The bug is clearly reproduced on the non-standard msp430-gcc target. However, the analysis of the expr.c code (see factor 1) indicates that this is a general GCC problem caused by rarely occurring factor combination, rather than bug in msp430 target implementation. To reproduce it outside this target, you need to combine 2 factors: supported USE_LOAD_POST_INCREMENT and supported PUSH_ARGS. You can alternatively build the msp430-gcc compiler (see http://mspgcc4.sourceforge.net/, the site provides an automatic downloading & building script) to see a non-broken gcc compiler having the problem (you will need to undo the fix applied by MSPGCC4 build script).
The problem is that "a case not used by mainstream ports is handled incorrectly by platform-independent part of GCC" and the problem now is to prove that the bug is common to gcc and not caused by msp430 port. Running a modified ARM port in debugger (setting breakpoint on mve_by_pieces()) can clearly illustrate, how GCC makes wrong decision to push the structure in a reversed way. The code making this decision (and generating move insns) does not depend on any other global definitions and is not related to the problem in __muldi3(). Finally, the m32c port defines both PUSH_ARGS and HAVE_POST_INCREMENT, so it can be possible to reproduce the bug on this port. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42722
