This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C as used/implemented in practice: analysis of responses


Sorry for my first misleading email. The code needs disabled
optimizations to ensure that the execution time is long enough
to measure jitter. It has nothing to do with the correctness of the
C code. It might be still an issue, to depend on an optimization level.

"To ensure that optimizations are the problem of the insufficient
execution jitter as the execution time is made too fast on fast,
but less complex CPUs, the same test without optimizations is
invoked again. To compile code without optimizations,
either use no special flags or -O0."

2015-06-29 22:19 GMT+02:00 Andreas Hollmann <hollmann@in.tum.de>:
> There is some recent code added to Linux 4.2, that relies on disabled
> optimization.
> This might be an interesting case of unclear interpretation/misuse of
> the C language.
>
> #ifdef __OPTIMIZE__
>  #error "The CPU Jitter random number generator must not be compiled
> with optimizations.
> See documentation. Use the compiler switch -O0 for compiling jitterentropy.c."
> #endif
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/crypto/jitterentropy.c
>
> Documentation: http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html
>
> 2015-06-27 1:48 GMT+02:00 Peter Sewell <Peter.Sewell@cl.cam.ac.uk>:
>> On 26 June 2015 at 20:27, Joseph Myers <joseph@codesourcery.com> wrote:
>>> On Fri, 26 Jun 2015, Peter Sewell wrote:
>>>
>>>> > It's s simple matter of points-to analysis.  &foo + anything may be
>>>> > assumed (in practice) to point to something within foo (or just past the
>>>> > end) and not to alias anything accessed through a pointer based on &bar.
>>>> > If the compiler can see something like &foo + (&bar - &foo) there is no
>>>> > guarantee of whether it will assume it to point within foo or bar and that
>>>> > may not be consistent for different uses (so it may end up concluding the
>>>> > pointer compares unequal to itself).
>>>>
>>>> Ok, that's fine in some (perhaps most) situations, but it's not
>>>> compatible with what seems to be a significant body of systems code
>>>> out there - people mentioned important usages in FreeBSD, Linux, QEMU,
>>>> and other places. How can these be reconciled?  We imagine:
>>>
>>> Does that code actually access the same object via both routes in code
>>> that might get moved past each other (or values get reused because the
>>> compiler didn't think they could have changed) as a consequence of the
>>> points-to analysis?  If the aliasing isn't visible, it's less likely to
>>> cause problems.
>>
>> It's a good question - quite possibly not, though it's hard to
>> investigate; really we have no idea.   But I'm not sure how we could
>> state a condition like that precisely in some reasonable way, and if
>> the conditions under which this is safe become too complex, that in
>> itself becomes a failing in the language definition - at the end of
>> the day, it has to be comprehensible.
>>
>> More generally, the programming-language design tradeoff between
>> simplicity on the one hand and performance and expressivity on the
>> other is always a difficult thing to manage.  The wide range of
>> opinions out there about what C behaviour can be relied on suggests
>> that C may have veered too far to the latter in some respects.
>>
>>>> a) Compilation of that systems code could turn off this analysis (and
>>>> whatever optimisation depends on it) entirely.  What's the cheapest
>>>> way to do that?
>>>
>>> I think -fno-tree-pta should disable it (I don't know what the cost of
>>> that is).
>>
>> thanks,
>> Peter
>>
>>
>>> --
>>> Joseph S. Myers
>>> joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]