qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 0/5] migration pull


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PULL 0/5] migration pull
Date: Tue, 23 Feb 2016 15:04:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0


On 23/02/2016 12:25, Peter Maydell wrote:
> On 23 February 2016 at 10:43, Peter Maydell <address@hidden> wrote:
>> That code fragment you suggest compiles fine normally, but not if I
>> add -save-temps:
>>
>> $ cat /tmp/zz9.c
>> #pragma GCC target("avx2")
>> #include <immintrin.h>
>> __m256i foo;
>> $ gcc -g -Wall -o /tmp/zz9.o -c /tmp/zz9.c
>> $ echo $?
>> 0
>> $ gcc -g -Wall -o /tmp/zz9.o -c /tmp/zz9.c -save-temps
>> /tmp/zz9.c:4:1: error: unknown type name ‘__m256i’
>>  __m256i foo;
>>  ^
>> /tmp/zz9.c: In function ‘bar’:
>> /tmp/zz9.c:7:19: error: ‘__m256i’ undeclared (first use in this function)
>>      return sizeof(__m256i);
>>                    ^
>> /tmp/zz9.c:7:19: note: each undeclared identifier is reported only
>> once for each function it appears in
>> /tmp/zz9.c:8:1: warning: control reaches end of non-void function
>> [-Wreturn-type]
>>  }
>>  ^
>>
>> This seems to be because -save-temps causes the #pragma not to
>> actually #define __AVX__.
> 
> This is because -save-temps causes gcc to invoke the
> preprocessor and the compiler as separate passes, and the
> standalone preprocessor doesn't know that the target pragma
> should result in a new #define, so the result is that the
> immintrin.h doesn't pull in what it should.
> 
> This is also the reason why my build failed -- I use ccache,
> which is another tool that results in the preprocessor being
> done as a standalone pass rather than in the same pass as
> compilation proper.
> 
> Arguably it's a gcc bug that the target pragma doesn't cause
> the standalone preprocessor to define the same #defines that
> you get if it's all in one pass, but regardless I don't think
> we can break ccache builds, so you'll need to find a different
> way to do this, I'm afraid.

It's a bug in the header file, it was fixed in 4.9.

https://gcc.gnu.org/ml/gcc-patches/2013-06/txtvBBiTsFs8g.txt

Amit or Liang, can you restrict the new optimization to GCC 4.9+?

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]