Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1380339 > unrolled thread

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: This patch triggers a bad gcc bug (was Re: [PATCH] force  inlining of some byteswap operations) Josh Poimboeuf <jpoimboe@redhat.com> - 2016-04-16 00:30 +0200
    Re: This patch triggers a bad gcc bug (was Re: [PATCH] force  inlining of some byteswap operations) Ingo Molnar <mingo@kernel.org> - 2016-04-16 11:10 +0200
      Re: This patch triggers a bad gcc bug (was Re: [PATCH] force  inlining of some byteswap operations) Josh Poimboeuf <jpoimboe@redhat.com> - 2016-04-18 15:40 +0200
        Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations) Arnd Bergmann <arnd@arndb.de> - 2016-04-18 16:10 +0200
          Re: This patch triggers a bad gcc bug (was Re: [PATCH] force  inlining of some byteswap operations) Josh Poimboeuf <jpoimboe@redhat.com> - 2016-04-18 16:20 +0200
            Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations) Arnd Bergmann <arnd@arndb.de> - 2016-04-18 16:30 +0200
        Re: This patch triggers a bad gcc bug (was Re: [PATCH] force  inlining of some byteswap operations) Ingo Molnar <mingo@kernel.org> - 2016-04-19 11:00 +0200
          [PATCH] scsi: fc: force inlining of wwn conversion functions Josh Poimboeuf <jpoimboe@redhat.com> - 2016-04-19 16:00 +0200
            Re: [PATCH] scsi: fc: force inlining of wwn conversion functions Quinn Tran <quinn.tran@qlogic.com> - 2016-04-23 01:20 +0200
            Re: [PATCH] scsi: fc: force inlining of wwn conversion functions Josh Poimboeuf <jpoimboe@redhat.com> - 2016-04-25 18:10 +0200
              Re: [PATCH] scsi: fc: force inlining of wwn conversion functions "Martin K. Petersen" <martin.petersen@oracle.com> - 2016-04-26 04:50 +0200
                Re: [PATCH] scsi: fc: force inlining of wwn conversion functions James Bottomley <James.Bottomley@HansenPartnership.com> - 2016-04-26 05:40 +0200
                  Re: [PATCH] scsi: fc: force inlining of wwn conversion functions Arnd Bergmann <arnd@arndb.de> - 2016-04-26 09:30 +0200
                    Re: [PATCH] scsi: fc: force inlining of wwn conversion functions Christoph Hellwig <hch@infradead.org> - 2016-04-26 10:40 +0200
                      Re: [PATCH] scsi: fc: force inlining of wwn conversion functions Arnd Bergmann <arnd@arndb.de> - 2016-04-26 12:10 +0200
                    Re: [PATCH] scsi: fc: force inlining of wwn conversion functions "Martin K. Petersen" <martin.petersen@oracle.com> - 2016-04-26 15:10 +0200
                      Re: [PATCH] scsi: fc: force inlining of wwn conversion functions Arnd Bergmann <arnd@arndb.de> - 2016-04-26 18:00 +0200
                        Re: [PATCH] scsi: fc: force inlining of wwn conversion functions James Bottomley <James.Bottomley@HansenPartnership.com> - 2016-04-27 00:40 +0200
                          Re: [PATCH] scsi: fc: force inlining of wwn conversion functions "Martin K. Petersen" <martin.petersen@oracle.com> - 2016-04-27 02:50 +0200
                        Re: [PATCH] scsi: fc: force inlining of wwn conversion functions Martin Jambor <mjambor@suse.cz> - 2016-04-27 13:10 +0200
                          Re: [PATCH] scsi: fc: force inlining of wwn conversion functions Arnd Bergmann <arnd@arndb.de> - 2016-04-27 23:40 +0200
                            Re: [PATCH] scsi: fc: force inlining of wwn conversion functions Arnd Bergmann <arnd@arndb.de> - 2016-04-28 17:30 +0200
                          [PATCH, RFT] byteswap: try to avoid __builtin_constant_p gcc bug Arnd Bergmann <arnd@arndb.de> - 2016-04-28 00:10 +0200
                            Re: [PATCH, RFT] byteswap: try to avoid __builtin_constant_p gcc bug Josh Poimboeuf <jpoimboe@redhat.com> - 2016-04-28 00:20 +0200
                              Re: [PATCH, RFT] byteswap: try to avoid __builtin_constant_p gcc bug Quinn Tran <quinn.tran@qlogic.com> - 2016-04-28 18:30 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1389599 — Re: [PATCH] scsi: fc: force inlining of wwn conversion functions

On Wednesday 27 April 2016 13:05:03 Martin Jambor wrote:
> On Tue, Apr 26, 2016 at 05:58:20PM +0200, Arnd Bergmann wrote:
> > On Tuesday 26 April 2016 09:06:54 Martin K. Petersen wrote:
> > > >>>>> "Arnd" == Arnd Bergmann <arnd@arndb.de> writes:
> > > 
> > > Arnd> I don't think we can realistically blacklist gcc-4.9.{0,1,2,3},
> > > Arnd> gcc-5.{0,1,2,3}.* and gcc-6.0 and require everyone to upgrade to
> > > Arnd> compilers that have not been released yet in order to build a
> > > Arnd> linux-4.6 kernel.
> > > 
> > > I agree that compiler blacklisting is problematic and I'd like to avoid
> > > it. The question is how far we go in the kernel to accommodate various
> > > levels of brokenness.
> > > 
> > > In any case. Sticking compiler workarounds in device driver code is akin
> > > to putting demolition orders on display on Alpha Centauri. At the very
> > > minimum the patch should put a fat comment in the code stating that
> > > these wrapper functions or #defines should not be changed in the future
> > > because that'll break builds using gcc XYZ. But that does not solve the
> > > problem for anybody else that might be doing something similar.
> > > Converting between u64 and $RANDOM_TYPE in an inline wrapper does not
> > > seem like a rare and unusual programming pattern.
> > 
> > It's not the driver really, it's the core scsi/fc layer, which makes
> > it a little dangerous that a random driver.
> > 
> > I agree that putting a comment in would also help. What I understand
> > from the bug report is that to trigger this bug you need these elements:
> > 
> > 1. an inline function marked __always_inline
> > 2. another inline function that is automatically inlined (not __always_inline)
> > 3. CONFIG_OPTIMIZE_INLINING=y to guarantee 2
> > 4. __builtin_compatible_p inside that inline function
> 
> The __always_inline requirement is not true.  In fact, if you look at
> the example testcase filed in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646#c7 you'll see it
> uses __builtin_compatible_p in an __always inline function that is
> called from one that is not tagged with that attribute.
>
> And generally speaking, always inline is never a requirement, any call
> or chain of calls that the inliner can decide to inline can lead to
> the bug (if it complies with the condition below).

Ok, thanks for the clarification, I thought you always had to have both
kinds of inline functions.
 
> What is a requirement, though, is that __builtin_compatible_p is
> called on something passed in an argument by reference or in an
> aggregate (i.e. struct or array) argument.
> 
> So,
> 
>   int foo1 (unsigned long *ref)
>   {
>     if (__builtin_constant (*ref))
>       ...
>     else
>       /* wrongly unreachable code */
>   }
> 
>   }
> 
> cannot, and is fine.  But please note that wrapping a foo[12]-like
> function into a dereferencing wrapper might not help if foo[12] would
> be early-inlined into such wrapper (GCC has two inliners, a very
> simple early-inliner that only handles simple cases and a full-blown
> IPA inliner that contains the bug).  I believe this can be ensured by
> making the wrapper always_inline and never calling it indirectly (via
> a pointer).  Honza (CCed), you know inlining heuristics better, please
> correct me if my last statement is somehow inaccurate (or indeed if
> you have a better idea how kernel developers can make sure they do not
> hit the bug).

I guess that means that any user of this code in the kernel:

static inline __attribute_const__ __u64 __fswab64(__u64 val)
{
#ifdef __HAVE_BUILTIN_BSWAP64__
        return __builtin_bswap64(val);
#elif defined (__arch_swab64)
        return __arch_swab64(val);
#elif defined(__SWAB_64_THRU_32__)
        __u32 h = val >> 32;
        __u32 l = val & ((1ULL << 32) - 1);
        return (((__u64)__fswab32(l)) << 32) | ((__u64)(__fswab32(h)));
#else
        return ___constant_swab64(val);
#endif
}

#define __swab64(x)                             \
        (__builtin_constant_p((__u64)(x)) ?     \
        ___constant_swab64(x) :                 \
        __fswab64(x))

static __always_inline __u64 __swab64p(const __u64 *p)
{       
#ifdef __arch_swab64p
        return __arch_swab64p(p);
#else
        return __swab64(*p);
#endif
}

has a chance of running into the same problem, and we may want to solve
it at the root. For architectures that define __HAVE_BUILTIN_BSWAP64__
(i.e. ARM, MIPS, POWERPC, S390, and x86 with gcc-4.4 or higher, 4.8
for __HAVE_BUILTIN_BSWAP16__), we can probably just change the logic
to avoid __builtin_constant_p() and always use __builtin_bswap64().

This won't help on TILE, which is the one architecture that sets
ARCH_SUPPORTS_OPTIMIZED_INLINING but does not set ARCH_USE_BUILTIN_BSWAP.
Chris Metcalf should be able to figure out whether we can just
set ARCH_USE_BUILTIN_BSWAP for tile as well.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1390307 — Re: [PATCH] scsi: fc: force inlining of wwn conversion functions

On Thursday 28 April 2016 10:58:43 Chris Metcalf wrote:
> (Resending as text/plain)
> 
> On 4/27/2016 5:34 PM, Arnd Bergmann wrote:
> > This won't help on TILE, which is the one architecture that sets
> > ARCH_SUPPORTS_OPTIMIZED_INLINING but does not set ARCH_USE_BUILTIN_BSWAP.
> > Chris Metcalf should be able to figure out whether we can just
> > set ARCH_USE_BUILTIN_BSWAP for tile as well.
> 
> We certainly could enable ARCH_USE_BUILTIN_BSWAP.  The only problem is
> that we never added explicit support for bswap16() in gcc, which is
> efficiently done on tilegx via the "revbytes" instruction and a 48-bit
> right-shift.  So gcc instead does a generic thing with four
> instructions in three bundles, so really not as good as our asm/swab.h.
> 
> I'm not sure how to weigh the implications of converting to
> builtin_bswap16 (and possibly upstreaming a better implementation to
> gcc), vs. disabling ARCH_SUPPORTS_OPTIMIZED_INLINING (which no one
> else but x86 uses anyway), vs. just ignoring the compiler bug and
> hoping it's not an issue in practice 

How about figuring out whether you hit the gcc bug on tile as a
first step?

Another idea would be to adapt this section in include/linux/compiler-gcc.h:

#if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) ||                \
    !defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
#define inline          inline          __attribute__((always_inline)) notrace
#define __inline__      __inline__      __attribute__((always_inline)) notrace
#define __inline        __inline        __attribute__((always_inline)) notrace
#else
/* A lot of inline functions can cause havoc with function tracing */
#define inline          inline          notrace
#define __inline__      __inline__      notrace
#define __inline        __inline        notrace
#endif

to work around the issue. We already check for gcc before 4.0, and
we could also check for the affected releases (4.9, 5.x, 6.1) in the
same place, possibly conditional on ARCH_USE_BUILTIN_BSWAP with
a comment pointing to the gcc bug tracker.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1389620 — [PATCH, RFT] byteswap: try to avoid __builtin_constant_p gcc bug

This is another attempt to avoid a regression in wwn_to_u64()
after that started using get_unaligned_be64(), which in turn
ran into a bug on gcc-4.9 through 6.1.

As part of the problem is how __builtin_constant_p gets evaluated
on an argument passed by reference into an inline function, this
avoids the use of __builtin_constant_p() for all architectures
that set CONFIG_ARCH_USE_BUILTIN_BSWAP. Most architectures do not
set ARCH_SUPPORTS_OPTIMIZED_INLINING, which means they probably
do not suffer from the problem in the qla2xxx driver, but they
might still run into it elsewhere.

I have not been able to reproduce the original problem, so I don't
know if this patch solves it, but at least it leads to simpler
code doing the same thing, so at least there should be no downsides.

Please test.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>

diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
index 3f10e5317b46..de56fd54428d 100644
--- a/include/uapi/linux/swab.h
+++ b/include/uapi/linux/swab.h
@@ -45,9 +45,7 @@
 
 static inline __attribute_const__ __u16 __fswab16(__u16 val)
 {
-#ifdef __HAVE_BUILTIN_BSWAP16__
-	return __builtin_bswap16(val);
-#elif defined (__arch_swab16)
+#if defined (__arch_swab16)
 	return __arch_swab16(val);
 #else
 	return ___constant_swab16(val);
@@ -56,9 +54,7 @@ static inline __attribute_const__ __u16 __fswab16(__u16 val)
 
 static inline __attribute_const__ __u32 __fswab32(__u32 val)
 {
-#ifdef __HAVE_BUILTIN_BSWAP32__
-	return __builtin_bswap32(val);
-#elif defined(__arch_swab32)
+#if defined(__arch_swab32)
 	return __arch_swab32(val);
 #else
 	return ___constant_swab32(val);
@@ -67,9 +63,7 @@ static inline __attribute_const__ __u32 __fswab32(__u32 val)
 
 static inline __attribute_const__ __u64 __fswab64(__u64 val)
 {
-#ifdef __HAVE_BUILTIN_BSWAP64__
-	return __builtin_bswap64(val);
-#elif defined (__arch_swab64)
+#if defined (__arch_swab64)
 	return __arch_swab64(val);
 #elif defined(__SWAB_64_THRU_32__)
 	__u32 h = val >> 32;
@@ -102,28 +96,40 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
  * __swab16 - return a byteswapped 16-bit value
  * @x: value to byteswap
  */
+#ifdef __HAVE_BUILTIN_BSWAP16__
+#define __swab16(x) __builtin_bswap16((__u16)(x))
+#else
 #define __swab16(x)				\
 	(__builtin_constant_p((__u16)(x)) ?	\
 	___constant_swab16(x) :			\
 	__fswab16(x))
+#endif
 
 /**
  * __swab32 - return a byteswapped 32-bit value
  * @x: value to byteswap
  */
+#ifdef __HAVE_BUILTIN_BSWAP32__
+#define __swab32(x) __builtin_bswap32((__u32)(x))
+#else
 #define __swab32(x)				\
 	(__builtin_constant_p((__u32)(x)) ?	\
 	___constant_swab32(x) :			\
 	__fswab32(x))
+#endif
 
 /**
  * __swab64 - return a byteswapped 64-bit value
  * @x: value to byteswap
  */
+#ifdef __HAVE_BUILTIN_BSWAP64__
+#define __swab64(x) __builtin_bswap64((__u64)(x))
+#else
 #define __swab64(x)				\
 	(__builtin_constant_p((__u64)(x)) ?	\
 	___constant_swab64(x) :			\
 	__fswab64(x))
+#endif
 
 /**
  * __swahw32 - return a word-swapped 32-bit value

[toc] | [prev] | [next] | [standalone]

#1389621 — Re: [PATCH, RFT] byteswap: try to avoid __builtin_constant_p gcc bug

On Thu, Apr 28, 2016 at 12:00:36AM +0200, Arnd Bergmann wrote:
> This is another attempt to avoid a regression in wwn_to_u64()
> after that started using get_unaligned_be64(), which in turn
> ran into a bug on gcc-4.9 through 6.1.
> 
> As part of the problem is how __builtin_constant_p gets evaluated
> on an argument passed by reference into an inline function, this
> avoids the use of __builtin_constant_p() for all architectures
> that set CONFIG_ARCH_USE_BUILTIN_BSWAP. Most architectures do not
> set ARCH_SUPPORTS_OPTIMIZED_INLINING, which means they probably
> do not suffer from the problem in the qla2xxx driver, but they
> might still run into it elsewhere.
> 
> I have not been able to reproduce the original problem, so I don't
> know if this patch solves it, but at least it leads to simpler
> code doing the same thing, so at least there should be no downsides.
> 
> Please test.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Nice patch.  I can confirm it fixes the issue with gcc 5.3.1.

Tested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>

> diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
> index 3f10e5317b46..de56fd54428d 100644
> --- a/include/uapi/linux/swab.h
> +++ b/include/uapi/linux/swab.h
> @@ -45,9 +45,7 @@
>  
>  static inline __attribute_const__ __u16 __fswab16(__u16 val)
>  {
> -#ifdef __HAVE_BUILTIN_BSWAP16__
> -	return __builtin_bswap16(val);
> -#elif defined (__arch_swab16)
> +#if defined (__arch_swab16)
>  	return __arch_swab16(val);
>  #else
>  	return ___constant_swab16(val);
> @@ -56,9 +54,7 @@ static inline __attribute_const__ __u16 __fswab16(__u16 val)
>  
>  static inline __attribute_const__ __u32 __fswab32(__u32 val)
>  {
> -#ifdef __HAVE_BUILTIN_BSWAP32__
> -	return __builtin_bswap32(val);
> -#elif defined(__arch_swab32)
> +#if defined(__arch_swab32)
>  	return __arch_swab32(val);
>  #else
>  	return ___constant_swab32(val);
> @@ -67,9 +63,7 @@ static inline __attribute_const__ __u32 __fswab32(__u32 val)
>  
>  static inline __attribute_const__ __u64 __fswab64(__u64 val)
>  {
> -#ifdef __HAVE_BUILTIN_BSWAP64__
> -	return __builtin_bswap64(val);
> -#elif defined (__arch_swab64)
> +#if defined (__arch_swab64)
>  	return __arch_swab64(val);
>  #elif defined(__SWAB_64_THRU_32__)
>  	__u32 h = val >> 32;
> @@ -102,28 +96,40 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
>   * __swab16 - return a byteswapped 16-bit value
>   * @x: value to byteswap
>   */
> +#ifdef __HAVE_BUILTIN_BSWAP16__
> +#define __swab16(x) __builtin_bswap16((__u16)(x))
> +#else
>  #define __swab16(x)				\
>  	(__builtin_constant_p((__u16)(x)) ?	\
>  	___constant_swab16(x) :			\
>  	__fswab16(x))
> +#endif
>  
>  /**
>   * __swab32 - return a byteswapped 32-bit value
>   * @x: value to byteswap
>   */
> +#ifdef __HAVE_BUILTIN_BSWAP32__
> +#define __swab32(x) __builtin_bswap32((__u32)(x))
> +#else
>  #define __swab32(x)				\
>  	(__builtin_constant_p((__u32)(x)) ?	\
>  	___constant_swab32(x) :			\
>  	__fswab32(x))
> +#endif
>  
>  /**
>   * __swab64 - return a byteswapped 64-bit value
>   * @x: value to byteswap
>   */
> +#ifdef __HAVE_BUILTIN_BSWAP64__
> +#define __swab64(x) __builtin_bswap64((__u64)(x))
> +#else
>  #define __swab64(x)				\
>  	(__builtin_constant_p((__u64)(x)) ?	\
>  	___constant_swab64(x) :			\
>  	__fswab64(x))
> +#endif
>  
>  /**
>   * __swahw32 - return a word-swapped 32-bit value
> 

-- 
Josh

[toc] | [prev] | [next] | [standalone]

#1390373 — Re: [PATCH, RFT] byteswap: try to avoid __builtin_constant_p gcc bug

-----Original Message-----
From: <linux-scsi-owner@vger.kernel.org> on behalf of Josh Poimboeuf <jpoimboe@redhat.com>
Date: Wednesday, April 27, 2016 at 3:11 PM
To: Arnd Bergmann <arnd@arndb.de>
Cc: Martin Jambor <mjambor@suse.cz>, "Martin K. Petersen" <martin.petersen@oracle.com>, James Bottomley <James.Bottomley@hansenpartnership.com>, linux-scsi <linux-scsi@vger.kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, Denys Vlasenko <dvlasenk@redhat.com>, Thomas Graf <tgraf@suug.ch>, Peter Zijlstra <peterz@infradead.org>, David Rientjes <rientjes@google.com>, Andrew Morton <akpm@linux-foundation.org>, Ingo Molnar <mingo@kernel.org>, Himanshu Madhani <himanshu.madhani@qlogic.com>, Dept-Eng QLA2xxx Upstream <qla2xxx-upstream@qlogic.com>, Jan Hubicka <hubicka@ucw.cz>
Subject: Re: [PATCH, RFT] byteswap: try to avoid __builtin_constant_p gcc bug

>On Thu, Apr 28, 2016 at 12:00:36AM +0200, Arnd Bergmann wrote:
>> This is another attempt to avoid a regression in wwn_to_u64()
>> after that started using get_unaligned_be64(), which in turn
>> ran into a bug on gcc-4.9 through 6.1.
>> 
>> As part of the problem is how __builtin_constant_p gets evaluated
>> on an argument passed by reference into an inline function, this
>> avoids the use of __builtin_constant_p() for all architectures
>> that set CONFIG_ARCH_USE_BUILTIN_BSWAP. Most architectures do not
>> set ARCH_SUPPORTS_OPTIMIZED_INLINING, which means they probably
>> do not suffer from the problem in the qla2xxx driver, but they
>> might still run into it elsewhere.
>> 
>> I have not been able to reproduce the original problem, so I don't
>> know if this patch solves it, but at least it leads to simpler
>> code doing the same thing, so at least there should be no downsides.
>> 
>> Please test.
>> 
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
>Nice patch.  I can confirm it fixes the issue with gcc 5.3.1.
>
>Tested-by: Josh Poimboeuf <jpoimboe@redhat.com>
>Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
>
>> diff --git a/include/uapi/linux/swab.h b/include/uapi/linux/swab.h
>> index 3f10e5317b46..de56fd54428d 100644
>> --- a/include/uapi/linux/swab.h
>> +++ b/include/uapi/linux/swab.h
>> @@ -45,9 +45,7 @@
>>  
>>  static inline __attribute_const__ __u16 __fswab16(__u16 val)
>>  {
>> -#ifdef __HAVE_BUILTIN_BSWAP16__
>> -	return __builtin_bswap16(val);
>> -#elif defined (__arch_swab16)
>> +#if defined (__arch_swab16)
>>  	return __arch_swab16(val);
>>  #else
>>  	return ___constant_swab16(val);
>> @@ -56,9 +54,7 @@ static inline __attribute_const__ __u16 __fswab16(__u16 val)
>>  
>>  static inline __attribute_const__ __u32 __fswab32(__u32 val)
>>  {
>> -#ifdef __HAVE_BUILTIN_BSWAP32__
>> -	return __builtin_bswap32(val);
>> -#elif defined(__arch_swab32)
>> +#if defined(__arch_swab32)
>>  	return __arch_swab32(val);
>>  #else
>>  	return ___constant_swab32(val);
>> @@ -67,9 +63,7 @@ static inline __attribute_const__ __u32 __fswab32(__u32 val)
>>  
>>  static inline __attribute_const__ __u64 __fswab64(__u64 val)
>>  {
>> -#ifdef __HAVE_BUILTIN_BSWAP64__
>> -	return __builtin_bswap64(val);
>> -#elif defined (__arch_swab64)
>> +#if defined (__arch_swab64)
>>  	return __arch_swab64(val);
>>  #elif defined(__SWAB_64_THRU_32__)
>>  	__u32 h = val >> 32;
>> @@ -102,28 +96,40 @@ static inline __attribute_const__ __u32 __fswahb32(__u32 val)
>>   * __swab16 - return a byteswapped 16-bit value
>>   * @x: value to byteswap
>>   */
>> +#ifdef __HAVE_BUILTIN_BSWAP16__
>> +#define __swab16(x) __builtin_bswap16((__u16)(x))
>> +#else
>>  #define __swab16(x)				\
>>  	(__builtin_constant_p((__u16)(x)) ?	\
>>  	___constant_swab16(x) :			\
>>  	__fswab16(x))
>> +#endif
>>  
>>  /**
>>   * __swab32 - return a byteswapped 32-bit value
>>   * @x: value to byteswap
>>   */
>> +#ifdef __HAVE_BUILTIN_BSWAP32__
>> +#define __swab32(x) __builtin_bswap32((__u32)(x))
>> +#else
>>  #define __swab32(x)				\
>>  	(__builtin_constant_p((__u32)(x)) ?	\
>>  	___constant_swab32(x) :			\
>>  	__fswab32(x))
>> +#endif
>>  
>>  /**
>>   * __swab64 - return a byteswapped 64-bit value
>>   * @x: value to byteswap
>>   */
>> +#ifdef __HAVE_BUILTIN_BSWAP64__
>> +#define __swab64(x) __builtin_bswap64((__u64)(x))
>> +#else
>>  #define __swab64(x)				\
>>  	(__builtin_constant_p((__u64)(x)) ?	\
>>  	___constant_swab64(x) :			\
>>  	__fswab64(x))
>> +#endif
>>  
>>  /**
>>   * __swahw32 - return a word-swapped 32-bit value
>> 

The patch works. Thanks.

>
>-- 
>Josh
>--
>To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web