On May 6, 2016 1:07:13 PM PDT, Sasha Levin wrote:
>On 05/04/2016 08:30 PM, H. Peter Anvin wrote:
>> On 05/04/16 15:06, John Denker wrote:
>>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
> Beware that shifting by an amount >= the number of bits in the
> word remains Undefined Behavior.
>>
On May 6, 2016 1:07:13 PM PDT, Sasha Levin wrote:
>On 05/04/2016 08:30 PM, H. Peter Anvin wrote:
>> On 05/04/16 15:06, John Denker wrote:
>>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
> Beware that shifting by an amount >= the number of bits in the
> word remains Undefined Behavior.
>>
On 05/04/2016 08:48 PM, Linus Torvalds wrote:
> That said, the fact that the other cases weren't changed
> (rol64/ror64/ror32) does make that argument less interesting. Unless
> there was some particular code that actively ended up using
> "rol32(..0)" but not the other cases.
Right, the others se
On 05/04/2016 08:30 PM, H. Peter Anvin wrote:
> On 05/04/16 15:06, John Denker wrote:
>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
Beware that shifting by an amount >= the number of bits in the
word remains Undefined Behavior.
>>
>>> This construct has been supported as a rotate since
>-- Perhaps the compiler guys could be persuaded to support
> the needed features explicitly, perhaps via a command-line
> option: -std=vanilla
> This should be a no-cost option as things stand today, but
> it helps to prevent nasty surprises in the future.
It looks LLVM has th
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 -
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 standard-co
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 standard-compliant
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 the
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.
> Suggestions:
>
> a) Going forward, I suggest that UB should not be invoked
> unless there is a good solid reason.
Good luck rewriting most of the kernel source.
This discussion is insane!
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a mess
- undefined behavior (UB)
The sizeof() example is LSO not UB. One could easily check
the sizes at compile time, so that no looseness remains.
The result is perfectly reasonable, efficient, reliable code.
Similarly, the kernel assumes two's complement arithmetic
"all over the place&quo
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 s
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 behavior
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 v
>>> 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, whic
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 th
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 the
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 consistent
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.
Its
On May 4, 2016 6:20:32 PM PDT, Jeffrey Walton wrote:
>On Wed, May 4, 2016 at 7:06 PM, Andi Kleen wrote:
>> On Wed, May 04, 2016 at 03:06:04PM -0700, John Denker wrote:
>>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
>>> >> Beware that shifting by an amount >= the number of bits in the
>>> >> wo
On Wed, May 4, 2016 at 7:06 PM, Andi Kleen wrote:
> On Wed, May 04, 2016 at 03:06:04PM -0700, John Denker wrote:
>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
>> >> Beware that shifting by an amount >= the number of bits in the
>> >> word remains Undefined Behavior.
>>
>> > This construct has b
On Wed, May 4, 2016 at 5:30 PM, H. Peter Anvin wrote:
>
> Yes. d7e35dfa is baloney IMNSHO. All it does is produce worse code, and the
> description even says so.
>
> As I said, gcc has treated the former code as idiomatic since gcc 2, so that
> support is beyond ancient.
Well, we're *trying* to
On 05/04/16 15:06, John Denker wrote:
On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
Beware that shifting by an amount >= the number of bits in the
word remains Undefined Behavior.
This construct has been supported as a rotate since at least gcc2.
How then should we understand the story told
On 05/04/2016 04:06 PM, Andi Kleen wrote:
> gcc always converts it before it could
[make a difference].
At the moment, current versions of gcc treat the idiomatic
ror/rol code as something they support ... but older versions
do not, and future version may not.
The gcc guys have made it very clea
On Wed, May 04, 2016 at 03:06:04PM -0700, John Denker wrote:
> On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
> >> Beware that shifting by an amount >= the number of bits in the
> >> word remains Undefined Behavior.
>
> > This construct has been supported as a rotate since at least gcc2.
>
> How t
On 05/04/2016 02:56 PM, H. Peter Anvin wrote:
>> Beware that shifting by an amount >= the number of bits in the
>> word remains Undefined Behavior.
> This construct has been supported as a rotate since at least gcc2.
How then should we understand the story told in commit d7e35dfa?
Is the story wr
tently applied.
Beware that shifting by an amount >= the number of bits in the
word remains Undefined Behavior. This should be either documented
or fixed. It could be fixed easily enough.
diff --git a/include/linux/bitops.h b/include/linux/bitops.h
index defeaac..90f389b 100644
--
28 matches
Mail list logo
