This is the mail archive of the 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

ack, thanks - in that case, it's a nice example, but not really
relevant to what we're asking about


On 30 June 2015 at 00:21, Andreas Hollmann <> wrote:
> 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 <>:
>> 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
>> Documentation:
>> 2015-06-27 1:48 GMT+02:00 Peter Sewell <>:
>>> On 26 June 2015 at 20:27, Joseph Myers <> 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

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