[PATCH v2, middle end]: Fix PR 37908, thinko with atomic NAND operation

[Richard Guenther]

On Wed, Oct 29, 2008 at 8:34 PM, David Daney <ddaney@caviumnetworks.com> wrote:
> Uros Bizjak wrote:
>>
>> David Daney wrote:
>>
>>>> Attached (now for real :) patch corrects __sync nand intrinsics to
>>>> generate ~(target & val). The patch was tested on i686-pc-linux-gnu. I
>>>> propose to commit the patch, since all unfixed targets will fail fixed
>>>> sync tests and after all targets are fixed, we can backport complete
>>>> patch to release branches and  add the note to release notes.
>>>>
>>>
>>> What is the motivation for getting this into 4.4 two days before the end
>>> of stage3?  It makes it more difficult for the maintainers of the ports you
>>> don't fix to have clean test results for 4.4.
>>
>> The motivation is, that the intrinsic does not operate correctly.  It is
>> wrong code bug, and this is certainly enough to warrant the change during
>> bugfix-only stage.
>
> The current implementation works as documented.  In theory I suppose you
> could consider it to be wrong-code, but it is not a regression.
>
>> I couldn't care less  for clean target test results, since two wrongs
>>  (wrong code and wrong test, to be precise) does not make right operation
>> here.
>>
>
> Agreed.
>
>
>>> As asked by APH in a different reply, Where are the nand intrinsics
>>> actually being used?
>>
>> So, if i.e. printf function produces wrong result - eats minus signs for
>> example -, this is OK then?
>
> If it had always been that way and changing it would break existing code
> that relied on existing behavior, clearly yes.
>
>> The fact that you don't need it doesn't mean that we can neglect published
>> standard (Intel ia64 intrinsics). IOW, the intrinsic will be changed before
>> 4.4 is released - IIRC, there were examples in the past when the release was
>> delayed because of wrong code bugs like that.
>
> The question I was trying to get an answer for is:  How grave is the
> situation?  And will fixing it cause more harm than good?
>
> That GCC behavior diverges from a 'published standard' is lamentable, you
> think we should change GCC to match the standard immediately, I wonder if
> there are better options.

Another option is to remove support for this function entirely and
re-introduce it
using a different name.

Ok, not seriously.  But my earlier suggestion still applies.

Richard.