Re: better patch for linux/bitops.h

On 05/05/2016 03:18 PM, ty...@mit.edu wrote: > > So this is why I tend to take a much more pragmatic viewpoint on > things. Sure, it makes sense to pay attention to what the C standard > writers are trying to do to us; but if we need to suppress certain > optimizations to write sane kernel code

Re: better patch for linux/bitops.h

On 05/05/2016 03:18 PM, ty...@mit.edu wrote: > > So this is why I tend to take a much more pragmatic viewpoint on > things. Sure, it makes sense to pay attention to what the C standard > writers are trying to do to us; but if we need to suppress certain > optimizations to write sane kernel code

Re: better patch for linux/bitops.h

On May 5, 2016 3:18:09 PM PDT, ty...@mit.edu wrote: >On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote: >> >> I completely fail to see why tests or compiler versions should be >> part of the discussion. The C standard says the behaviour in >> certain cases is undefined, so a

Re: better patch for linux/bitops.h

On May 5, 2016 3:18:09 PM PDT, ty...@mit.edu wrote: >On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote: >> >> I completely fail to see why tests or compiler versions should be >> part of the discussion. The C standard says the behaviour in >> certain cases is undefined, so a

Re: better patch for linux/bitops.h

On 05/05/2016 03:18 PM, ty...@mit.edu wrote: > On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote: >> >> I completely fail to see why tests or compiler versions should be >> part of the discussion. The C standard says the behaviour in >> certain cases is undefined, so a

Re: better patch for linux/bitops.h

On 05/05/2016 03:18 PM, ty...@mit.edu wrote: > On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote: >> >> I completely fail to see why tests or compiler versions should be >> part of the discussion. The C standard says the behaviour in >> certain cases is undefined, so a

Re: better patch for linux/bitops.h

On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote: > > I completely fail to see why tests or compiler versions should be > part of the discussion. The C standard says the behaviour in > certain cases is undefined, so a standard-compliant compiler > can generate more-or-less any code

Re: better patch for linux/bitops.h

On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote: > > I completely fail to see why tests or compiler versions should be > part of the discussion. The C standard says the behaviour in > certain cases is undefined, so a standard-compliant compiler > can generate more-or-less any code

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: > Instead of arguing over who's "sane" or "insane", can we come up with > a agreed upon set of tests, and a set of compiler and compiler > versions ... I completely fail to see why tests or compiler versions should be part of

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: > Instead of arguing over who's "sane" or "insane", can we come up with > a agreed upon set of tests, and a set of compiler and compiler > versions ... I completely fail to see why tests or compiler versions should be part of the discussion.

Re: better patch for linux/bitops.h

On 05/04/16 21:03, Jeffrey Walton wrote: On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: ... But instead of arguing over what works and doesn't, let's just create the the test set and just try it on a wide range of compilers and architectures, hmmm? What are the

Re: better patch for linux/bitops.h

On 05/04/16 21:03, Jeffrey Walton wrote: On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: ... But instead of arguing over what works and doesn't, let's just create the the test set and just try it on a wide range of compilers and architectures, hmmm? What are the requirements? Here's a

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: > ... > But instead of arguing over what works and doesn't, let's just create > the the test set and just try it on a wide range of compilers and > architectures, hmmm? What are the requirements? Here's a short list: * No

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: > ... > But instead of arguing over what works and doesn't, let's just create > the the test set and just try it on a wide range of compilers and > architectures, hmmm? What are the requirements? Here's a short list: * No undefined

Re: better patch for linux/bitops.h

Instead of arguing over who's "sane" or "insane", can we come up with a agreed upon set of tests, and a set of compiler and compiler versions for which these tests must achieve at least *working* code? Bonus points if they achieve optimal code, but what's important is that for a wide range of GCC

Re: better patch for linux/bitops.h

Instead of arguing over who's "sane" or "insane", can we come up with a agreed upon set of tests, and a set of compiler and compiler versions for which these tests must achieve at least *working* code? Bonus points if they achieve optimal code, but what's important is that for a wide range of GCC

Re: better patch for linux/bitops.h

>>> So you are actually saying outright that we should sacrifice *actual* >>portability in favor of *theoretical* portability? What kind of >>twilight zone did we just step into?! >> >>I'm not sure what you mean. It will be well defined on all platforms. >>Clang may not recognize the pattern,

Re: better patch for linux/bitops.h

>>> So you are actually saying outright that we should sacrifice *actual* >>portability in favor of *theoretical* portability? What kind of >>twilight zone did we just step into?! >> >>I'm not sure what you mean. It will be well defined on all platforms. >>Clang may not recognize the pattern,

Re: better patch for linux/bitops.h

On May 4, 2016 7:54:12 PM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 10:41 PM, H. Peter Anvin wrote: >> On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton >wrote: >>>On Wed, May 4, 2016 at 5:52 PM, John Denker wrote:

Re: better patch for linux/bitops.h

On May 4, 2016 7:54:12 PM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 10:41 PM, H. Peter Anvin wrote: >> On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton >wrote: >>>On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: On 05/04/2016 02:42 PM, I wrote: > I find it very odd that

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 10:41 PM, H. Peter Anvin wrote: > On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton wrote: >>On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: >>> On 05/04/2016 02:42 PM, I wrote: >>> I find it very odd that the other

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 10:41 PM, H. Peter Anvin wrote: > On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton wrote: >>On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: >>> On 05/04/2016 02:42 PM, I wrote: >>> I find it very odd that the other seven functions were not upgraded. I suggest

Re: better patch for linux/bitops.h

On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: >> On 05/04/2016 02:42 PM, I wrote: >> >>> I find it very odd that the other seven functions were not >>> upgraded. I suggest the attached fix-others.diff

Re: better patch for linux/bitops.h

On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: >> On 05/04/2016 02:42 PM, I wrote: >> >>> I find it very odd that the other seven functions were not >>> upgraded. I suggest the attached fix-others.diff would make >>> things more

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: > On 05/04/2016 02:42 PM, I wrote: > >> I find it very odd that the other seven functions were not >> upgraded. I suggest the attached fix-others.diff would make >> things more consistent. > > Here's a replacement patch. > ... +1,

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: > On 05/04/2016 02:42 PM, I wrote: > >> I find it very odd that the other seven functions were not >> upgraded. I suggest the attached fix-others.diff would make >> things more consistent. > > Here's a replacement patch. > ... +1, commit it.

Re: better patch for linux/bitops.h

On 05/04/2016 02:42 PM, I wrote: > I find it very odd that the other seven functions were not > upgraded. I suggest the attached fix-others.diff would make > things more consistent. Here's a replacement patch. Same idea, less brain damage. Sorry for the confusion. commit

Re: better patch for linux/bitops.h

On 05/04/2016 02:42 PM, I wrote: > I find it very odd that the other seven functions were not > upgraded. I suggest the attached fix-others.diff would make > things more consistent. Here's a replacement patch. Same idea, less brain damage. Sorry for the confusion. commit