To follow up on this... I was going to build/install the library, turning optimization on one source file at a time until the defect manifested itself again. Once that happened, I was going to do side-by-side diffs of objdumps of the binary both with and without optimization (because I wasn't sure if just passing -S to gcc would be sufficient or not... some linkers do some fairly impressive reordering of code based of prediction, cache alignment, etc and hence the final object might still be substantially different than what the compiler generated). Are there test tools available that can be used to isolate differences in generated code from one compiler to another? Thanks. On 8/28/10 12:41 PM, Philip Prindeville wrote:
Hi. I work a bit with Asterisk, the IP-PBX open software. There's a GSM library that's included in the source tree. The problem we're encountering is that when compiled with gcc 4.1.x and 4.3 or later, it works fine. But some of our target platforms only support gcc 4.2, and when we compile against this, the optimizer in GCC exposes the fact that someone writing some ASM stubs forgot to correctly annotate a constraint, and that lack of a constraint is causing the optimizer to change the generated object more than it should. There are a lot of lines of source code, and most of my experience with asm() stubs has been rudimentary, so I'm asking for an outside pair of eyeballs that might be better skilled at identifying how the asm should be annotated than me. The suspect code is here: http://svnview.digium.com/svn/asterisk/trunk/codecs/gsm/inc/private.h?view=markup Previous tweaks to the annotation were: http://svnview.digium.com/svn/asterisk/branches/1.6.0/codecs/gsm/inc/private.h?r1=111858&r2=111857&pathrev=111858 but I suspect there's something still missing. Any help would be appreciated as this issue has been dogging us for a couple of years now. Thanks, -Philip
