[LLVMdev] C as used/implemented in practice: analysis of responses
David Keaton
dmk at dmk.com
Thu Jul 2 21:17:30 PDT 2015
On 07/02/2015 08:51 PM, Philip Reames wrote:
>> The title of Annex L is Analyzability, because that was the
>> purpose, but the effect was to define a stricter abstract machine in
>> which there were no unbounded undefined behaviors except what was
>> absolutely necessary. That does not address every question in the
>> questionnaire, but it is a good start, and it has already been
>> standardized so there is something concrete to implement.
> IMHO, the Annex completely fails to be useful for the purpose you
> intend. The definition of "bounded undefined behavior" is phrased in
> terms of "may", not "must". The wording doesn't appear to require a
> choice from the list; it merely states some possible implementations.
> Unless I'm reading it wrong, the only real restriction is against out of
> bounds stores. On the surface, it doesn't even seem to prevent out of
> bounds stores in the program being exposed by a transformation. It only
> prevents an out of bounds store in the undefined operation itself. That
> really doesn't get you much of anything.
The word "may" does not appear in Annex L. There are some
nonnormative notes that indicate some things that might happen if the
normative text is followed. The annex specifies that most undefined
behavior "shall" be limited to bounded undefined behavior.
The implications are nuanced. An implementation that conforms to
Annex L is prevented from performing some optimizations because it must
ensure that no out-of-bounds store would be created out of bounded
undefined behavior. In other words, in the general case, it can no
longer make the assumption that bounded undefined behavior does not occur.
> Consider:
> y is positive
> a = x + y (signed overflow, wrapping "expected")
> if (a >= x)
> store out of bounds
> ===>
> store out of bounds
Right. This is not prevented because the programmer has specified
an out-of-bounds store. However, if the programmer had not done so, the
implementation would be prevented from making a transformation that
results in an out-of-bounds store.
David
More information about the llvm-dev
mailing list