This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Optimization breaks inline asm code w/ptrs

gcc 6.1
compiling for 64bit i386
optimizations: -O2

Consider this simple bit of code (from

#include <stdio.h>

int getStringLength(const char *pStr){

    int len;

    __asm__  (
        "repne scasb\n\t"
        "not %%ecx\n\t"
        "dec %%ecx"
        :"=c" (len), "+D"(pStr)
        :"c"(-1), "a"(0)

    return len;

int main()
   char buff[50] = "hello world";
   int a = getStringLength(buff);
   printf("%s: %d\n", buff, a);

This code works as expected and prints out 11.  Yay.

However, if you add "buff[4] = 0;" before the call to getStringLength, it STILL prints out 11 (when optimizations are enabled), when it should print 4.

I would expect this kind of behavior if the asm were in 'main.' But it has always been my understanding that function calls performed an implicit memory clobber. The fact that this clobber goes away during inlining means that code can stop working any time the compiler makes a different decision about whether or not to inline a function. Ouch.

And before somebody asks:  Adding "+m"(pStr) does not help.

The result is that (apparently) you can NEVER safely pass a buffer pointer to inline asm without using the memory clobber. If this is true, I don't believe it is widely known.

Given how 'heavy' memory clobbers are, I would hope that only pointers that have 'escaped' the function would get flushed before a function call. But not flushing *anything* seems very bad.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]