[RFC PATCH] sna: Fix build with gcc 5.0

[RFC PATCH] sna: Fix build with gcc 5.0

[Olivier Fourdan]

gcc generates an error at build time because it fails to inline some
functions:

  blt.c: In function 'affine_blt':
  blt.c:980:1: error: inlining failed in call to always_inline
  'bilinear_weight': optimization level attribute mismatch
   bilinear_weight(pixman_fixed_t x)

  blt.c:1164:7: error: called from here
      fy = bilinear_weight(y1);
         ^
  blt.c:980:1: error: inlining failed in call to always_inline
  'bilinear_weight': optimization level attribute mismatch
   bilinear_weight(pixman_fixed_t x)

  blt.c:1163:7: error: called from here
      fx = bilinear_weight(x1);
         ^
  blt.c:989:1: error: inlining failed in call to always_inline
  'bilinear_interpolation': optimization level attribute mismatch
   bilinear_interpolation(uint32_t tl, uint32_t tr,
   ^
  blt.c:1207:11: error: called from here
      b[i] = bilinear_interpolation(tl, tr, bl, br, fx, fy);
           ^

Do not force inlining of these functions and let the compiler decide to
avoid the compilation failure.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
---
 Note: It could be a gcc bug, I am not sure, I don't know enough of
       gcc internals to tell, that's why I post this patch as "RFC".

 src/sna/blt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/sna/blt.c b/src/sna/blt.c
index a2472c1..687fb40 100644
--- a/src/sna/blt.c
+++ b/src/sna/blt.c
@@ -976,7 +976,7 @@ memcpy_xor(const void *src, void *dst, int bpp,
 }
 
 #define BILINEAR_INTERPOLATION_BITS 4
-static force_inline int
+static inline int
 bilinear_weight(pixman_fixed_t x)
 {
 	return (x >> (16 - BILINEAR_INTERPOLATION_BITS)) &
@@ -985,7 +985,7 @@ bilinear_weight(pixman_fixed_t x)
 
 #if BILINEAR_INTERPOLATION_BITS <= 4
 /* Inspired by Filter_32_opaque from Skia */
-static force_inline uint32_t
+static inline uint32_t
 bilinear_interpolation(uint32_t tl, uint32_t tr,
 		       uint32_t bl, uint32_t br,
 		       int distx, int disty)
-- 
2.3.6

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC PATCH] sna: Fix build with gcc 5.0

[Chris Wilson]

On Fri, Apr 24, 2015 at 09:43:37AM +0200, Olivier Fourdan wrote:
> gcc generates an error at build time because it fails to inline some
> functions:
> 
>   blt.c: In function 'affine_blt':
>   blt.c:980:1: error: inlining failed in call to always_inline
>   'bilinear_weight': optimization level attribute mismatch

Does this mean anything more specific (than just it not being able to
inline)?

>  Note: It could be a gcc bug, I am not sure, I don't know enough of
>        gcc internals to tell, that's why I post this patch as "RFC".

Since bilinear_weight() is trivial and bilinear_interpolation() is only
called from one location, I wonder what is up?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC PATCH] sna: Fix build with gcc 5.0

[Chris Wilson]

On Fri, Apr 24, 2015 at 09:43:37AM +0200, Olivier Fourdan wrote:
> gcc generates an error at build time because it fails to inline some
> functions:
> 
>   blt.c: In function 'affine_blt':
>   blt.c:980:1: error: inlining failed in call to always_inline
>   'bilinear_weight': optimization level attribute mismatch
>    bilinear_weight(pixman_fixed_t x)
> 
>   blt.c:1164:7: error: called from here
>       fy = bilinear_weight(y1);
>          ^
>   blt.c:980:1: error: inlining failed in call to always_inline
>   'bilinear_weight': optimization level attribute mismatch
>    bilinear_weight(pixman_fixed_t x)
> 
>   blt.c:1163:7: error: called from here
>       fx = bilinear_weight(x1);
>          ^
>   blt.c:989:1: error: inlining failed in call to always_inline
>   'bilinear_interpolation': optimization level attribute mismatch
>    bilinear_interpolation(uint32_t tl, uint32_t tr,
>    ^
>   blt.c:1207:11: error: called from here
>       b[i] = bilinear_interpolation(tl, tr, bl, br, fx, fy);
>            ^
> 
> Do not force inlining of these functions and let the compiler decide to
> avoid the compilation failure.
> 
> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>

Fixed up the other two force_inlines there and pushed,

commit 9b9643171359194478ab9f7126012b659d2ae7a1
Author: Olivier Fourdan <ofourdan@redhat.com>
Date:   Fri Apr 24 09:43:37 2015 +0200

    sna: Fix build with gcc 5.0

Thanks,
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC PATCH] sna: Fix build with gcc 5.0

[Olivier Fourdan]

Hi Chris,

On 24/04/15 10:11, Chris Wilson wrote:
> On Fri, Apr 24, 2015 at 09:43:37AM +0200, Olivier Fourdan wrote:
>> gcc generates an error at build time because it fails to inline some
>> functions:
>>
>>    blt.c: In function 'affine_blt':
>>    blt.c:980:1: error: inlining failed in call to always_inline
>>    'bilinear_weight': optimization level attribute mismatch
>
> Does this mean anything more specific (than just it not being able to
> inline)?
>
>>   Note: It could be a gcc bug, I am not sure, I don't know enough of
>>         gcc internals to tell, that's why I post this patch as "RFC".
>
> Since bilinear_weight() is trivial and bilinear_interpolation() is only
> called from one location, I wonder what is up?

Humm, that looks definitely dodgy, now the build fails a bit further 
when _FORTIFY_SOURCE is set to 2:


In file included from /usr/include/string.h:639:0,
                  from /usr/include/xorg/os.h:53,
                  from /usr/include/xorg/misc.h:115,
                  from /usr/include/xorg/xf86str.h:37,
                  from sna.h:43,
                  from blt.c:32:
blt.c: In function 'memcpy_from_tiled_x__swizzle_9_10_11':
/usr/include/bits/string3.h:50:42: error: inlining failed in call to 
always_inline 'memcpy': optimization level attribute mismatch
  __NTH (memcpy (void *__restrict __dest, const void *__restrict __src,
                                           ^
blt.c:474:1314: error: called from here
In file included from /usr/include/string.h:639:0,
                  from /usr/include/xorg/os.h:53,
                  from /usr/include/xorg/misc.h:115,
                  from /usr/include/xorg/xf86str.h:37,
                  from sna.h:43,
                  from blt.c:32:
/usr/include/bits/string3.h:50:42: error: inlining failed in call to 
always_inline 'memcpy': optimization level attribute mismatch
  __NTH (memcpy (void *__restrict __dest, const void *__restrict __src,
                                           ^
blt.c:474:1605: error: called from here
In file included from /usr/include/string.h:639:0,
                  from /usr/include/xorg/os.h:53,
                  from /usr/include/xorg/misc.h:115,
                  from /usr/include/xorg/xf86str.h:37,
                  from sna.h:43,
                  from blt.c:32:
/usr/include/bits/string3.h:50:42: error: inlining failed in call to 
always_inline 'memcpy': optimization level attribute mismatch
  __NTH (memcpy (void *__restrict __dest, const void *__restrict __src,
                                           ^
blt.c:474:1865: error: called from here
Makefile:650: recipe for target 'blt.lo' failed


Yet, *not* setting _FORTIFY_SOURCE seems to work around the issue. I 
find it weird the error is with the inlining of memcpy() ...

I'll double check on the gcc side and report back once I know more :)

Cheers,
Olivier
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [RFC PATCH] sna: Fix build with gcc 5.0

[Olivier Fourdan]

On 24/04/15 10:43, Olivier Fourdan wrote:
[...]

> Yet, *not* setting _FORTIFY_SOURCE seems to work around the issue. I
> find it weird the error is with the inlining of memcpy() ...
>
> I'll double check on the gcc side and report back once I know more :)

Quick follow-up, I checked with Jakub and he confirmed this is a gcc issue:

    http://gcc.gnu.org/PR65873

So we should be all set, once this gcc bug is addressed.

Thanks!
Olivier

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx